Created attachment 142708 [details] Visual Glitch on Dolphin (Wayland window) but not on Firefox (XWayland) SUMMARY I have key bindings to move a window to other virutal desktops. When I trigger the shortcut on a Wayland window, there's a visual glitch as shown in screen recording. The key bindings work just fine for XWayland windows. The window which is intended to move looks to be stuck but if I click somewhere or sometimes on hover, the ghost window goes away. This does not happen if I move window to other VD using right click menu on task manager or window header. STEPS TO REPRODUCE 1. Set a key binding to move window to other VD 2. Use the key binding on a wayland window. Example: Dolphin OBSERVED RESULT The window moves to the intended VD but leaves a ghost window which goes away if I click anywhere or press any key. EXPECTED RESULT The window should move to the intended VD without leaving any visual artifact. SOFTWARE/OS VERSIONS Linux/KDE Plasma: Arch Linux (available in About System) KDE Plasma Version: 5.23.1 KDE Frameworks Version: 5.87.0 Qt Version: 5.15.2
if you disable the slide back effect, can you reproduce the bug? iirc the slide back does some stacking order magic
(In reply to Vlad Zahorodnii from comment #1) > if you disable the slide back effect, can you reproduce the bug? iirc the > slide back does some stacking order magic I can still reproduce it. I don't think it has anything to do with slide back because the visual glitch is present even when I have only one window opened on screen.
I don't fully understand what's going on in the video. Why does firefox disappear at the start of the video? is this a bug or intentional?
My bad, since I am using keybindings it is not very clear what is happening. The firefox window is disappearing because the I am using the keybinding to push it to the other VD. As stated the visual glitch is not present on XWayland windows and I am just demonstrating that Firefox, running on XWayland, does not have glitch. Later in the video, I am using the same keybinding on Dolphin, which is a wayland window. The window actually moves to the other VD but the window leaves an artifact. Tip: You can notice when I am using the keybinding by looking at task manager at the bottom, Dolphine disappears from the task manager but the visual artifact remains. Timestamps where I used keybindings: 0:03 (Firefox), 0:05 (Firefox), 0:11 (Dolphin), 0:21 (Dolphin), 0:26 (Dolphin) Hope you understand now!
Same issue as Bug 438552?
(In reply to Nate Graham from comment #5) > Same issue as Bug 438552? I don't have translucency effect or glide effect enabled. The ghost window goes away if I click somewhere or press a key. Also, it only effects Wayland windows.
This glitch is also visible when using Pager widget for both Activities and Virtual Desktops. Just drag the window from one VD/Activity to other VD/Activity and the window artifacts are left behind unless something gets updated on screen. It works just as expected if I use right click menu of the window in task manager to move it to VD/Activity. Editing the title to reflect this observation.
*** Bug 445436 has been marked as a duplicate of this bug. ***
Can confirm on Neon unstable, though only if more than one monitor is active.
(In reply to Firlaev-Hans from comment #9) > Can confirm on Neon unstable, though only if more than one monitor is active. Never mind the "only with more than one monitor" thing. I can reproduce it with only one monitor on the latest Neon unstable as well, but only some of the time, whereas it happens every single time with two monitors.
I can reproduce this on both Fedora and Archlinux.
*** Bug 448676 has been marked as a duplicate of this bug. ***
A possibly relevant merge request was started @ https://invent.kde.org/plasma/kwin/-/merge_requests/2004
Git commit a4bb3896bfeb716efebd768404915f0414c65068 by Vlad Zahorodnii. Committed on 12/02/2022 at 12:06. Pushed by vladz into branch 'master'. Schedule workspace repaint when window leaves current desktop When a window leaves the current virtual desktop, we need to schedule a workspace repaint so the compositor repaints the old region of the window on the current desktop. In hindsight, the scene graph must schedule a repaint, but it's not doable with the current effects api, it will be changed with future refactoring changes. M +3 -1 src/abstract_client.cpp https://invent.kde.org/plasma/kwin/commit/a4bb3896bfeb716efebd768404915f0414c65068
Git commit ee65fb3d2fca84a706d17c9fa6d41641fedbd757 by Vlad Zahorodnii. Committed on 12/02/2022 at 12:26. Pushed by vladz into branch 'Plasma/5.24'. Schedule workspace repaint when window leaves current desktop When a window leaves the current virtual desktop, we need to schedule a workspace repaint so the compositor repaints the old region of the window on the current desktop. In hindsight, the scene graph must schedule a repaint, but it's not doable with the current effects api, it will be changed with future refactoring changes. (cherry picked from commit a4bb3896bfeb716efebd768404915f0414c65068) M +3 -1 src/abstract_client.cpp https://invent.kde.org/plasma/kwin/commit/ee65fb3d2fca84a706d17c9fa6d41641fedbd757
*** Bug 450405 has been marked as a duplicate of this bug. ***
It appears that Bug 450405 might have been the root cause for this ghost window glitch, and while the workspace repaint fixes this symptom, the bug that caused it is still present. Take a look at that bug report for details, but TL;DR KWin apparently still considers a (non-XWayland) window to be the currently focused window even after it leaves the current workspace.