Created attachment 152107 [details] Screen recording STEPS TO REPRODUCE 1. Two screens (2k@100% + 4k@200% primary) 2. Maximize the window on one screen 3. Drag the window by its titlebar OBSERVED RESULT The window expands over the other screen for a split second before it becomes a non-maximized window. Please see the screen recording. SOFTWARE/OS VERSIONS Operating System: openSUSE Tumbleweed 20220914 KDE Plasma Version: 5.26.80 KDE Frameworks Version: 5.98.0 Qt Version: 5.15.5 Kernel Version: 5.19.8-1-default (64-bit) Graphics Platform: Wayland Graphics Processor: AMD Radeon RX 580 Series
Created attachment 152108 [details] kWin Support Info
I can reproduce this issue. Operating System: Kubuntu 22.04 KDE Plasma Version: 5.25.90 KDE Frameworks Version: 5.98.0 Qt Version: 5.15.3 Kernel Version: 5.15.0-47-generic (64-bit) Graphics Platform: X11 Processors: 8 × Intel® Core™ i7-7700HQ CPU @ 2.80GHz Memory: 15.5 GiB of RAM Graphics Processor: NVIDIA GeForce GTX 1060/PCIe/SSE2 Manufacturer: Micro-Star International Co., Ltd. Product Name: GP62MVR 7RFX System Version: REV:1.0
5.26
I can see a little in 5.25.5 but much clear in latest 5.25.90
It looks like the extent of how much the window bleeds to another screen depends on where you start dragging the window.
Should we change important of this ticket to minor?
The problem is that kwin can process interactive move while the window has not committed a new buffer after unmaximizing it. https://invent.kde.org/-/snippets/2349 makes kwin delay processing move requests until the client provides a new buffer, however this has its own bugs, e.g. you won't be able to move a window if it's unresponsive, etc. Needs more thinking how to handle async geometry updates in this case.
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 449105, 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
*** Bug 484239 has been marked as a duplicate of this bug. ***