Created attachment 156746 [details] readds "if (interactiveMoveResizeGravity() != Gravity::None)" SUMMARY When Chromium windows with client-side decorations are when snapped to a tile, focusing the browser window by single-clicking on the tab header will cause the window to lose it's tiling and return to it's previous size. This occurs with both the new Shift+drag Custom Tiling, and legacy Quick Tiling (after the commit where the new tiling was introduced). Tiling functions normally with client-side decorations off, but this is less than ideal. So far I can only identify Chromium+Chrome as affected, Firefox behaves like normal with similar client-side decorations to Chromium. Of course, Chromium's decorations are outside of Kwin scope, but I may have found a fix, below. STEPS TO REPRODUCE 1. Open Chromium with "Use system title bar and borders" disabled, note the window size before snapping. 2. Snap the window to a tile using either the new Shift modifier, or the old quick corners/keys. 3. Click the blank space in the title bar once, the window will lose it's snapping and return to original size. OBSERVED RESULT Window leaves tile and jumps back to original size, keeps position EXPECTED RESULT Window should focus/activate and remain static in the tile unless dragged or double-clicked (maximize) SOFTWARE/OS VERSIONS Linux/KDE Plasma: Arch / Plasma 5.27.1 (and master) ADDITIONAL INFORMATION The issue was introduced when the new Custom Tiling system was integrated, I found this particular block affects the windows in question: https://invent.kde.org/plasma/kwin/-/commit/e4507861f7b5ba563ae7cd5ce036a42a09f9edf8?page=2#4901cf4a1e41ceabcf8333e2929683619d4f0698_1664_1663 Adding the extra if check back in seems to resolve the issue for me, the Chromium windows behave as expected and stay snapped to the new and old tiles when focusing. if (m_tile && !m_tile->supportsResizeGravity(interactiveMoveResizeGravity())) { if (interactiveMoveResizeGravity() != Gravity::None) { setQuickTileMode(QuickTileFlag::None); } } Attached the patch i'm testing with. I'm still tinkering so I can understand the particulars and find out if there are adverse effects.
I'm experiencing the same unwanted unsnapping when using another Chromium based browser: Microsoft Edge. It acts the same on both my Steam Deck running Arch and another desktop machine running Kubuntu (version 5.27 from backports-extra). A non-browser app that also has this problem is the Steam desktop app. Which clearly has its own custom titlebar. It seems as if clicking these custom title bars, triggers dragging of the window. The same unwanted behaviour happens with windows snapped to the edge of the screen, when tiled using the native tiling feature or when using a Kwin tiling script like Karousel.
Can reproduce. Any interest in submitting that patch upstream? Thanks for digging into it so deeply!
(In reply to Nate Graham from comment #2) > Can reproduce. Any interest in submitting that patch upstream? Thanks for > digging into it so deeply! Hello yes! This MR has the patch: https://invent.kde.org/plasma/kwin/-/merge_requests/3794 It's noted that it only addressed half of the snapping code, handleInteractiveMoveResize() also needs updated to support the new custom quick tiling. As it were, I still use the old quicksnapping gestures 100% of the time, so I did forget all about this one! Just added the check on my local, compiling to test now.
Ah great, thanks! Feel free to ask for help in that MR if you're feeling stuck on anything.
Hello, sorry for the late update. It's noted in this PR that isInteractiveResize() was addressed some time ago: https://invent.kde.org/plasma/kwin/-/merge_requests/3794. This is true for old quick-tiled windows, but I notice the issue still occurs when clicking the header of a Chromium window in a custom tile: it will pop back to it's windowed state. Alas, I don't use Chromium (anymore) or the custom tiling (yet), but I can confirm this combination still has the issue.
*** Bug 488721 has been marked as a duplicate of this bug. ***
(In reply to Blazer Silving from comment #5) > Hello, sorry for the late update. It's noted in this PR that > isInteractiveResize() was addressed some time ago: > https://invent.kde.org/plasma/kwin/-/merge_requests/3794. This is true for > old quick-tiled windows, but I notice the issue still occurs when clicking > the header of a Chromium window in a custom tile: it will pop back to it's > windowed state. > > Alas, I don't use Chromium (anymore) or the custom tiling (yet), but I can > confirm this combination still has the issue. The same issue is present when using Firefox with client-side decorations (which is the default on Fedora). I have no title bar (to save screen real estate), so when I tile one window to the left of the screen and another to the right, I'll frequently attempt to click on a tab in Firefox and it will cause the window to un-tile. This is quite frustrating and disruptive.
(In reply to Stephen Gallagher from comment #7) > The same issue is present when using Firefox with client-side decorations > (which is the default on Fedora). > > I have no title bar (to save screen real estate), so when I tile one window > to the left of the screen and another to the right, I'll frequently attempt > to click on a tab in Firefox and it will cause the window to un-tile. This > is quite frustrating and disruptive. Hey, yes I use Firefox (or any browser) exactly the same way, tab bar at the very top with left and right half tiling, and it is very annoying when they un-tile. The top few pixels can't be used to select a tab, unlike when the window is Maximized. However, I believe this is an upstream Firefox bug, they fixed it for GNOME and only GNOME: https://bugzilla.mozilla.org/show_bug.cgi?id=1550721. I spun up a base ubuntu VM with GNOME to test and sure enough it works exactly as it should. I've been meaning to submit a bug report there regarding KDE, but I want to try and integrate their GNOME fix first to see if that's all it needs, just haven't had time.
It seems the upstream problem is actually twofold: - Firefox does not detect tiled state in KDE. This means things like the left tab spacer will always be visible, you can observe it disappear when maximized and when tiled in GNOME and reappear when untiled. To note, this behavior is also broken in Windows and likely every platform except GNOME/GTK native (and I hid it in CSS a long time ago). Forcing `gtktiledwindow=true` obviously works to set the mode but this needs to be detected somehow. Will be opening a bug with Mozilla, but don't expect much on this one, as the following issue still applies: - Even with the tiled mode above, there is a conditional check to always draw the resize handle on top and bottom in KDE, even while tiled: // On KDE, allow for 1 extra pixel at the top of regular windows when // drawing to the titlebar. This matches the native titlebar behavior on // that environment. See bug 1813554. // // Don't do that on GNOME (see bug 1822764). If we wanted to do this on // GNOME we'd need an extra check for mIsTiled, since the window is "stuck" // to the top and bottom. // // Other DEs are untested. return mDrawInTitlebar && IsKdeDesktopEnvironment(); (https://bugzilla.mozilla.org/show_bug.cgi?id=1813554 https://bugzilla.mozilla.org/show_bug.cgi?id=1822764) This may have been required at some point, but taking this one line out actually fixed my issue! The Firefox windows stay tiled and the top pixels can be used to select tabs now. When in a quick or custom tile, the resizers are still drawn as they should be on the open edge, not the edges shared with a screen. Just installed the patched Firefox, going to test it and bring both bugs to their attention very soon if this actually works as it seems to.
Nice, feel free to share any links to upstream that we can follow.
Yes, the Firefox top-most resizer issue is definitely upstream. I'm still gathering information before submitting a report, but I'm not sure Firefox has the ability to read the window hints that Kwin uses when tiled. While removing the resize 1px buffer does partially resolve the issue, the proper way is to read the tiled state and act accordingly. That's going to be my next place to investigate and will require a full kwin debugging setup. In fact, with latest Google Chrome/Chromium and the patched Firefox, I cannot replicate the untiling bug in X11 or Wayland for any other application. These browsers are likely the only cause of this bug because of their unique tabs-on-top decoration. I might record a video of the Firefox behavior to ensure we're discussing the same bug, but it looks like Chromium is fully fixed in this regard. Chromium has changed much with their new UI, so I suppose a fix was included there for the edge case I noted a few months ago.
Hey, for those still following, I have opened the upstream bug with Firefox: https://bugzilla.mozilla.org/show_bug.cgi?id=1919115
*** Bug 493005 has been marked as a duplicate of this bug. ***