SUMMARY In the Plasma 5.24 beta, when dragging a window's titlebar to "unsnap" it and make it windowed, the mouse cursor seems to pretty much always move to the top left corner instead of trying to keep a sensible cursor position relative to the new window size. This does not seem to affect Xwayland applications such as Steam or Chromium running without Wayland Ozone, only Wayland applications both GTK and Qt. Tested Firefox with Wayland enabled, Dolphin, Konsole and System Settings. STEPS TO REPRODUCE 1. Maximise a native Wayland application, such as System Settings 2. Drag the window down from the top of the screen to make it windowed 3. Mouse cursor will move to the top left corner and window position will be offset. OBSERVED RESULT Mouse cursor position almost always moves to the top left corner when "unsnapping" a window, the only reliable exception being some Xwayland applications I have tested. However, there are instances where this simply doesn't happen with native Wayland applications. It happened once when Konsole when testing for this report. I had two Konsole windows open, one produced the incorrect behaviour and one worked correctly. When opening several new Konsole windows after this, all of them exhibited the buggy behaviour. This is the only instance where a native Wayland application has had this problem. EXPECTED RESULT Dragging maximised windows from the top should place the mouse cursor in a more sane position, which was the behaviour in the latest stable Plasma 5.23.5. SOFTWARE/OS VERSIONS Linux/KDE Plasma: 5.16.2-arch1-1 KDE Plasma Version: 5.23.90 KDE Frameworks Version: 5.90 Qt Version: 5.15.2 ADDITIONAL INFORMATION - Have not tested X11 - Affects both my multi-monitor PC setup and my single-display laptop
Cannot reproduce with a single screen.
Fixed in 5.24
I'm still having a problem with this on plasma 5.24.4. It happens to me consistently on Dolphin but only if the window is opened in maximised form: 1. Open plasma wayland session 2. Open Dolphin file manager (for example) 3. Maximise Dolphin 4. Close Dolphin 5. Open Dolphin again 6. Try to move the window by dragging.
Ah, I can reproduce the issue with those exact steps too.
*** Bug 453447 has been marked as a duplicate of this bug. ***
Still applies to windows that open maximised in 5.24.90
*** Bug 457601 has been marked as a duplicate of this bug. ***
Can't reproduce in 5.26 Beta.
Me neither, looks like it's fixed now, hooray!
(In reply to Nate Graham from comment #9) > Me neither, looks like it's fixed now, hooray! Oddly, I can still easily reproduce it. Tried the latest Neon Unstable and Testing builds in a VM as well as the latest Manjaro Plasma daily build in live boot (as it includes the proprietary NVIDIA driver OOB), same result in all of them. Took the exact same steps as listed in comment 3.
Created attachment 152678 [details] reproducer I still see this issue with this reproducer script in 5.25.90 on Arch. kwin 5.25.90-1 qt5-base 5.15.6+kde+r177-1 qt5-wayland 5.15.6+kde+r50-1
Interesting. I can reproduce it with that script too (after changing it to use PyQt5). Thanks!
*** Bug 462262 has been marked as a duplicate of this bug. ***
After living a long time with this bug assuming it'd eventually be fixed I finally decided to take look it up on the bug tracker... and to my surprise it does not have a lot of attention? It's been happening forever on all my machines, where display scaling, gtk vs qt, multiple monitors vs single monitor, all don't matter. I can assume everyone is affected. Super annoying. I would argue this a 15-minute bug.
(In reply to Alessandro Astone from comment #14) > After living a long time with this bug assuming it'd eventually be fixed I > finally decided to take look it up on the bug tracker... and to my surprise > it does not have a lot of attention? > It's been happening forever on all my machines, where display scaling, gtk > vs qt, multiple monitors vs single monitor, all don't matter. I can assume > everyone is affected. > Super annoying. I would argue this a 15-minute bug. I'm running 5.27 and it's still an issue. It's not functionality breaking but you do notice it quickly and it's quite annoying. I'm seeing it right now when opening new Firefox windows. It's happened on every system I've tried including Intel, AMD, NVIDIA Graphics, Virtualbox too.
I can reproduce it easily on any Wayland application in Plasma 5.27.4 As reported by another user above, it happens only when dragging a new window that opens maximized (also with meta+left click drag from any position inside the window, not just from the titlebar) Can confirm also that XWayland applications are unaffected Only workaround is to not use drag to unsnap the window Tested single/multi-screen, no maximize animations, NVIDIA/Intel My steps to reproduce it: 1. Open Konsole 2. Maximize Konsole (no need to close it) 3. Open new Konsole window 4. Drag to unsnap the window
(In reply to Alessandro Astone from comment #14) > After living a long time with this bug assuming it'd eventually be fixed I > finally decided to take look it up on the bug tracker... and to my surprise > it does not have a lot of attention? I'm similarly surprised. I'm constantly opening new windows and moving them around to other monitors. Those windows are almost always maximized. As a result there's this weird dance I have to do with the mouse each time. How so few are reporting this is kinda wild. Do KDE users (and KDE maintainers in particular) not use large or multimonitor setups? Or just not have many open maximized windows? I could see someone exclusively alt-tabbing and/or switching virtual desktops if you almost always rock a single moderate screen, like on a laptop. I'm curious what the statistics would look like for user screen arrangement data, that is if there was any sort of opt-in metrics collecting.
Since the issue only happens when dragging specific windows that were opened in specific circumstances from their titlebars, we can assume that many people don't do exactly those things. Personally I maximize and de-maximize windows all the time but I do it via the keyboard, not the mouse. We do in fact have telemetry for screen usage and though I can't give exact numbers because the data isn't public, I can tell you that the percentage of users of multi-screen setups and large screens is indeed fairly low. Not "single digits" low, but low nonetheless.
(In reply to miranda from comment #17) > (In reply to Alessandro Astone from comment #14) > Do KDE users (and KDE maintainers in particular) not use large or > multimonitor setups? Or just not have many open maximized windows? FWIW, whether one uses a large screen or a multi-monitor setup is irrelevant for this bug. It happens on any number of screens and any size/resolution of display(s). Just tested the latest Neon user edition in a VM with it's default screen setup of 1 display at 1024x768 and it occurs there. (In reply to Nate Graham from comment #18) > Since the issue only happens when dragging specific windows that were opened > in specific circumstances from their titlebars, we can assume that many > people don't do exactly those things. > > Personally I maximize and de-maximize windows all the time but I do it via > the keyboard, not the mouse. I don't believe it requires as complex circumstances as you may be suggesting. All it takes to trigger it is a window opening in maximized state, that's it. If you try moving the window with your mouse after that, you'll see the bug and will continue to every time without fail until the application is re-opened in a de-maximized state. If a window is opened in a de-maximized state, then maximized and moved with the mouse, the bug does not trigger. If one is using keybinds to move windows around, they won't experience this bug of course. However, I'd think it's a (poweruser) minority of users who are doing that compared to those who are using the mouse. While relatively minor, I'd argue this should be on the 15-minute bug list with as little as it takes to trigger it, for how often and basic the action of moving a window is, and for how annoying it can become in rather short time.
*** Bug 470838 has been marked as a duplicate of this bug. ***
Same was also happening on GNOME. It doesn't matter how many screens you have. I have this issue on my laptop which has just one builtin display. This is really annoying bug especially with touchpad when you always need to grab the window from wrong position. Also the window is totally messing it's position when you try to resize it. In mutter it was fixed https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2942?commit_id=7eb01304259b5977feaee3b2d0a2073b70312d89 Is it possible to use in in kwin?
Created attachment 159586 [details] dragging window
(In reply to Ondřej Niesner from comment #21) > Same was also happening on GNOME. It doesn't matter how many screens you > have. I have this issue on my laptop which has just one builtin display. > This is really annoying bug especially with touchpad when you always need to > grab the window from wrong position. Also the window is totally messing it's > position when you try to resize it. > > In mutter it was fixed > https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/ > 2942?commit_id=7eb01304259b5977feaee3b2d0a2073b70312d89 > > Is it possible to use in in kwin? Hello, I also have this problem. Maybe an easier approach is to check in `void Window::startDelayedInteractiveMoveResize()` to determine if the window was maximized (and then doing the anchor coordinates) similar to how it is done in `bool Window::startInteractiveMoveResize()` in `window.cpp`. It is my first time posting, please correct me if I did anything wrong
*** Bug 471342 has been marked as a duplicate of this bug. ***
A possibly relevant merge request was started @ https://invent.kde.org/plasma/kwin/-/merge_requests/4302
*** Bug 473084 has been marked as a duplicate of this bug. ***
*** Bug 471884 has been marked as a duplicate of this bug. ***
*** Bug 475871 has been marked as a duplicate of this bug. ***
*** Bug 478197 has been marked as a duplicate of this bug. ***
*** Bug 478886 has been marked as a duplicate of this bug. ***
Hello! I previously reported a bug that was similar to this that was merged as a duplicate. After reading through the comments, I feel I should add a few of my observations that don't seem to be reflected here: 1. The issue appears to occur on any window that is opened in the maximised state **BUT is resolved by clicking "restore down" and clicking "maximise"** 2. Whilst the bug is in effect, dragging the window by the title bar moves the cursor to the top left and offsets the window, as documented 3. After dragging the window, if you release the mouse and attempt to resize the window by dragging the top-left corner or left/top edges will cause the window to jump to the opposite side of the cursor. [screenshot attached] I've found that the bug is also prevented if you drag either the bottom or right edges of the window.
(In reply to Sollace from comment #32) > Hello! > > I previously reported a bug that was similar to this that was merged as a > duplicate. After reading through the comments, I feel I should add a few of > my observations that don't seem to be reflected here: > > 1. The issue appears to occur on any window that is opened in the maximised > state **BUT is resolved by clicking "restore down" and clicking "maximise"** > > 2. Whilst the bug is in effect, dragging the window by the title bar moves > the cursor to the top left and offsets the window, as documented > 3. After dragging the window, if you release the mouse and attempt to resize > the window by dragging the top-left corner or left/top edges will cause the > window to jump to the opposite side of the cursor. [screenshot attached] > > > I've found that the bug is also prevented if you drag either the bottom or > right edges of the window. Addendum: switching focus to another window ALSO appears to resolve the bug.
*** Bug 480585 has been marked as a duplicate of this bug. ***
*** Bug 482465 has been marked as a duplicate of this bug. ***
A possibly relevant merge request was started @ https://invent.kde.org/plasma/kwin/-/merge_requests/5399
A possibly relevant merge request was started @ https://invent.kde.org/plasma/kwin/-/merge_requests/5404
Git commit 2c7301b3eea93e345c36cd89a72e41ec5d421861 by Vlad Zahorodnii. Committed on 11/03/2024 at 20:16. Pushed by vladz into branch 'master'. Make Window::interactiveMoveOffset() relative Window::interactiveMoveOffset() stores the move offset in pixels, but it is somewhat annoying to deal with when the window size changes, for example when the window is unmaximized. This change makes Window::interactiveMoveOffset() store a ratio where the move offset can be found. This simplifies the code a bit and fixes the cursor jumping to the topleft window corner. Although there are other glitches. M +1 -2 src/events.cpp M +14 -23 src/window.cpp M +0 -9 src/window.h M +1 -2 src/xdgshellwindow.cpp https://invent.kde.org/plasma/kwin/-/commit/2c7301b3eea93e345c36cd89a72e41ec5d421861
(In reply to Vlad Zahorodnii from comment #38) > Git commit 2c7301b3eea93e345c36cd89a72e41ec5d421861 by Vlad Zahorodnii. > Committed on 11/03/2024 at 20:16. > Pushed by vladz into branch 'master'. > > Make Window::interactiveMoveOffset() relative > > Window::interactiveMoveOffset() stores the move offset in pixels, but it > is somewhat annoying to deal with when the window size changes, for example > when the window is unmaximized. > > This change makes Window::interactiveMoveOffset() store a ratio where > the move offset can be found. This simplifies the code a bit and fixes > the cursor jumping to the topleft window corner. Although there are other > glitches. > > M +1 -2 src/events.cpp > M +14 -23 src/window.cpp > M +0 -9 src/window.h > M +1 -2 src/xdgshellwindow.cpp > > https://invent.kde.org/plasma/kwin/-/commit/ > 2c7301b3eea93e345c36cd89a72e41ec5d421861 I want to confim: this issue isn't only about the cursor jumping to the top-left, right? It is also that the entire window gets displaced to the far top-left past the cursor when attempting to resize it by dragging either the top or left edge or corner handles.
(In reply to Sollace from comment #39) > I want to confim: this issue isn't only about the cursor jumping to the > top-left, right? It is also that the entire window gets displaced to the far > top-left past the cursor when attempting to resize it by dragging either the > top or left edge or corner handles. this bug report is about the issue described in https://bugs.kde.org/show_bug.cgi?id=449105#c0 if there are other issues, file separate bug reports
(In reply to Vlad Zahorodnii from comment #40) > (In reply to Sollace from comment #39) > > I want to confim: this issue isn't only about the cursor jumping to the > > top-left, right? It is also that the entire window gets displaced to the far > > top-left past the cursor when attempting to resize it by dragging either the > > top or left edge or corner handles. > > this bug report is about the issue described in > https://bugs.kde.org/show_bug.cgi?id=449105#c0 > > if there are other issues, file separate bug reports I did, however my report was marked as a duplicate of this one.
Feel free to unmark it as a duplicate if you feel it reports something different.
Git commit 11a5513e789e2bd9a99f19d2b8477ca4700ab46d by Vlad Zahorodnii. Committed on 15/03/2024 at 18:00. Pushed by vladz into branch 'master'. Avoid moving the window while it's maximized Unlike X11, on Wayland, the window won't change its maximize mode until it renders a new buffer. This creates a problem for interactive move because if it's not careful and moves the window while it's still effectively maximized, it will look as if the window has leaked to other screens. This change fixes the problem by making Window::handleInteractiveMoveResize() avoid move() if the window needs to be unmaximized. As a bonus, it also allows to unmaximize the windows that are maximized along only one dimension by dragging them. Unfortunately, tiling stuff still suffers from the same issue. In order to fix it, Window::tile() has to be part of double buffered state, like Window::maximizeMode(). Related: bug 459218, bug 482085 M +1 -0 autotests/integration/kwin_wayland_test.h M +18 -0 autotests/integration/test_helpers.cpp M +312 -0 autotests/integration/xdgshellwindow_test.cpp M +28 -13 src/window.cpp M +9 -0 src/x11window.cpp M +11 -0 src/xdgshellwindow.cpp https://invent.kde.org/plasma/kwin/-/commit/11a5513e789e2bd9a99f19d2b8477ca4700ab46d
was the fix merged for 6.0.3?
No. 6.1