Bug 376155

I'm seeing this behavior too, though for the tiling behavior by dragging the window to a screen edge. It happens also for windows that were tiled when opened and not just the maximized ones.

This is ArchLinux package.

I suspect that this is caused by 

```
commit 9934f5b57537feae54afd0c4366c90253638ada2
Author: Martin Gräßlin <mgraesslin@kde.org>
Date:   Fri Sep 16 14:27:50 2016 +0200

    Properly implement maximize of ShellClient

    Summary:
    This brings some more checks from Client to ShellClient. Thus the
    states are better adjusted.

    Unfortunately the X11 implementation is also slightly adjusted, so could
    create regressions in worst case.

    BUG: 368393

    Reviewers: #kwin, #plasma_on_wayland

    Subscribers: plasma-devel, kwin

    Tags: #plasma_on_wayland, #kwin

    Differential Revision: https://phabricator.kde.org/D3507
```

And I assume this might be one of the "worst case".

The following patch seems to fix the issue for me locally though I'm not sure if it's the right solution. I'll submit a review if no one proposed a better solution in a few days.


```
diff --git a/geometry.cpp b/geometry.cpp
index 64b5d67ca..420549aeb 100644
--- a/geometry.cpp
+++ b/geometry.cpp
@@ -3333,11 +3333,11 @@ void AbstractClient::setQuickTileMode(QuickTileMode mode, bool keyboard)
             m_quickTileMode = QuickTileNone; // Temporary, so the maximize code doesn't get all confused
             setGeometry(electricBorderMaximizeGeometry(keyboard ? geometry().center() : Cursor::pos(), desktop()), geom_mode);
         }
+        setMaximize(false, false);
+
         // Store the mode change
         m_quickTileMode = mode;

-        setMaximize(false, false);
-
         emit quickTileModeChanged();

         return;
```

Yes I also suspected that this commit is the one causing the regression. What we need is a test case which clearly shows the problem and ensure that we don't break again. After all for Wayland Windows we have that already 😉

Does KWin support automatic testing on X now?

Also does that change look correct? The symptom AFAICT is definitely that `m_quickTileMode` is changed from `0` to `1` (or the other way around, don't remember) after `setMaximize` returns.

Git commit 8b4f284249f1ff6a52b7148c0536164c42ceaa73 by Martin Gräßlin.
Committed on 14/02/2017 at 06:29.
Pushed by graesslin into branch 'Plasma/5.9'.

[autotests] Add test case for quick tiling on X11

Exposes our regressions of X11 quick tiling when a window is vertically
maximized.

M  +1    -1    autotests/integration/CMakeLists.txt
M  +183  -0    autotests/integration/quick_tiling_test.cpp

https://commits.kde.org/kwin/8b4f284249f1ff6a52b7148c0536164c42ceaa73

> Does KWin support automatic testing on X now?

yes it can :-)

This bug is still present in plasma 5.9.3. Yichao, did you ever get around to submitting your patch?

No, there's a slightly different behavior that I cannot fix even with my patch so I didn't submitted it (the behavior might be new in 5.2). This time, instead of simply untile (and doesn't move), it does not resize (and didn't receive any restore size signal as printing in kwin code shows) when I drag it but restores it's original (untiled) size when I try to tile it. The difference of the end result is that the window is moved, but the size is still wrong.

*** Bug 376224 has been marked as a duplicate of this bug. ***

Moving `setMaximize(false, false);` further up (to revert the problematic commit) seems to fix the issue on my kwin 5.9.4/openSUSE 42.2.


```
--- a/geometry.cpp      2017-03-21 21:54:36.000000000 +0800
+++ b/geometry.cpp      2017-03-23 19:11:02.872123167 +0800
@@ -3326,6 +3326,8 @@
 
         TabSynchronizer syncer(this, TabGroup::QuickTile|TabGroup::Geometry|TabGroup::Maximized);
 
+        setMaximize(false, false);
+        
         if (mode != QuickTileNone) {
             m_quickTileMode = mode;
             // decorations may turn off some borders when tiled
@@ -3336,8 +3338,6 @@
         // Store the mode change
         m_quickTileMode = mode;
 
-        setMaximize(false, false);
-
         emit quickTileModeChanged();
 
         return;
```

This bug is still present in fedora and arch.

(In reply to sedrubal from comment #11)
> This bug is still present in fedora and arch.

Of course it is, if it were fixed it would be marked as fixed.

Why is this bug still "UNCONFIRMED"? And Platrform is not only Gentoo, but also fedora, arch and most likely all distros ;)

(In reply to sedrubal from comment #13)
> Why is this bug still "UNCONFIRMED"?

That's probably the most often question we get: unconfirmed has no meaning at all on bugs.kde.org. It is only there for $REASONS.

*** Bug 380005 has been marked as a duplicate of this bug. ***

*** Bug 380468 has been marked as a duplicate of this bug. ***

*** Bug 381824 has been marked as a duplicate of this bug. ***

@Till
The version field "defines the version of the software the bug was (first) found in.", hence you should leave to 5.9 and not bump the version...

*** This bug has been marked as a duplicate of bug 376104 ***