Bug 444172

Summary: [Wayland] Ghost window left behind when moving wayland windows to other VD/Activity using key bindings or pager widget
Product: [Plasma] kwin Reporter: Bacteria <dev.bacteriostat>
Component: wayland-genericAssignee: KWin default assignee <kwin-bugs-null>
Status: RESOLVED FIXED    
Severity: normal CC: dev.bacteriostat, firlaevhans.fiete, grasm, nate, postix
Priority: HI Keywords: wayland
Version: 5.23.90   
Target Milestone: ---   
Platform: Other   
OS: Linux   
See Also: https://bugs.kde.org/show_bug.cgi?id=450473
https://bugs.kde.org/show_bug.cgi?id=450405
Latest Commit: Version Fixed In: 5.24.1
Sentry Crash Report:
Attachments: Visual Glitch on Dolphin (Wayland window) but not on Firefox (XWayland)

Description Bacteria 2021-10-21 08:27:39 UTC
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
Comment 1 Vlad Zahorodnii 2021-10-21 08:32:20 UTC
if you disable the slide back effect, can you reproduce the bug? iirc the slide back does some stacking order magic
Comment 2 Bacteria 2021-10-21 08:56:21 UTC
(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.
Comment 3 Vlad Zahorodnii 2021-10-21 09:01:11 UTC
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?
Comment 4 Bacteria 2021-10-21 09:11:26 UTC
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!
Comment 5 Nate Graham 2021-10-21 14:52:09 UTC
Same issue as Bug 438552?
Comment 6 Bacteria 2021-10-21 15:08:07 UTC
(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.
Comment 7 Bacteria 2021-11-22 05:10:56 UTC
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.
Comment 8 Firlaev-Hans 2021-12-04 12:34:49 UTC
*** Bug 445436 has been marked as a duplicate of this bug. ***
Comment 9 Firlaev-Hans 2021-12-04 12:40:53 UTC
Can confirm on Neon unstable, though only if more than one monitor is active.
Comment 10 Firlaev-Hans 2021-12-29 10:55:42 UTC
(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.
Comment 11 Matthieu Gras 2022-01-13 21:41:50 UTC
I can reproduce this on both Fedora and Archlinux.
Comment 12 postix 2022-01-28 18:45:43 UTC
*** Bug 448676 has been marked as a duplicate of this bug. ***
Comment 13 Bug Janitor Service 2022-02-12 11:21:01 UTC
A possibly relevant merge request was started @ https://invent.kde.org/plasma/kwin/-/merge_requests/2004
Comment 14 Vlad Zahorodnii 2022-02-12 12:26:12 UTC
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
Comment 15 Vlad Zahorodnii 2022-02-12 12:26:45 UTC
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
Comment 16 Nate Graham 2022-02-17 23:07:51 UTC
*** Bug 450405 has been marked as a duplicate of this bug. ***
Comment 17 Firlaev-Hans 2022-02-18 13:43:36 UTC
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.