SUMMARY On wayland if you move any native window to a different workspace it still appears focused in the pager applet (though not in the 3rd party "Window title" applet), still responds to keyboard input, and can still be moved with KWin shortcuts, even though it's now on a different workspace, until you focus something else. XWayland apps are not affected. STEPS TO REPRODUCE 1. Have keyboard shortcuts set for moving windows to specific virtual desktops 2. Open a native Wayland window (not XWayland). I suggest something like Kate or Konsole will let you type something. 3. Move it to a different VD. Take a look at the desktop pager widget. 4. Type something. 5. Without clicking on anything, press the according keyboard shortcut to move the active window to the desktop you are currently on OBSERVED RESULT 3. The window will be displayed in the pager applet on the new VD, but it will still be colored as if it was the active window 5. The previously moved window will come back to the current workspace. If you did step 4. then you'll notice that the window accepted keyboard input while it wasn't even on the active workspace. EXPECTED RESULT After a window is moved to a different VD, it should not have focus anymore. Thus, it should also no longer accept keyboard input, and KWin shortcuts shouldn't affect it anymore either. SOFTWARE/OS VERSIONS Operating System: Arch Linux KDE Plasma Version: 5.24.1 KDE Frameworks Version: 5.91.0 Qt Version: 5.15.2 Kernel Version: 5.16.9-zen1-1-zen (64-bit) Graphics Platform: Wayland
*** This bug has been marked as a duplicate of bug 444172 ***
I do not believe this is a duplicate of the bug you linked, at least not exactly. At the very least, the fix for the ghost window bug in 5.24.1 did not fix this bug. It seems likely that this bug was the root cause for the ghost windows bug; Since the native Wayland window is still "focused" after leaving the workspace it would still be drawn, or at least its area would not be repainted, until you actively focus something else. But the ghost window bug ended up getting fixed by repainting the workspace after a window leaves the VD, which only fixed the symptom and not the root cause. So while we no longer get the visual artifact, the window is still considered the focused window by KWin and receives keyboard input while on a different workspace, even in the latest Plasma version.
I can reproduce this with Kate: if I open Kate on desktop 1, and then use a keyboard shortcut to move it to desktop 2, when I stay on desktop 1 and continue typing the Kate window on desktop 2 receives my keyboard input.
I think the XWayland comment is very interesting: Wayland window reproduction: you can see that after moving the Wayland window to another desktop, it is still marked as active in the virtual desktop pager widget, but also no window on the current virtual desktop is active: there is definitely only one active window and it is on another desktop. XWayaldn window reproduction: you can see that after moving the XWayland window to another desktop, the XWayland window is *not* marked as active in the virtual desktop pager widget, but no other window - on the current desktop or otherwise - is shown as active: there are now no active windows. That isn't in itself a bug as this is a valid behavior - for example when clicking on the desktop. My main issue with the "move window to another desktop" behavior is that I would have expected one of the windows on the current desktop to become active, possibly in stacking order, but maybe the above behavior is more correct - no window should be active after you moved the current one to a new desktop.