Bug 450405

Summary:	After moving a native Wayland window to a different virtual desktop it is still considered focused
Product:	[Plasma] kwin	Reporter:	Firlaev-Hans <firlaevhans.fiete>
Component:	wayland-generic	Assignee:	KWin default assignee <kwin-bugs-null>
Status:	RESOLVED DUPLICATE
Severity:	normal	CC:	dev.bacteriostat, nate, oded, philipp.reichmuth, postix
Priority:	NOR
Version:	5.24.1
Target Milestone:	---
Platform:	Arch Linux
OS:	Linux
See Also:	https://bugs.kde.org/show_bug.cgi?id=444172
Latest Commit:		Version Fixed In:
Sentry Crash Report:

Description Firlaev-Hans 2022-02-16 20:01:21 UTC

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

Comment 1 Nate Graham 2022-02-17 23:07:51 UTC


*** This bug has been marked as a duplicate of bug 444172 ***

Comment 2 Firlaev-Hans 2022-02-18 13:38:43 UTC

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.

Comment 3 phrxmd 2022-02-19 08:27:34 UTC

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.

Comment 4 Oded Arbel 2024-02-23 12:23:16 UTC

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.

Comment 5 Firlaev-Hans 2024-08-12 09:56:46 UTC

Since Bug 481574 is technically a duplicate of this bug but the discussion is happening there now I guess I'll mark this one as duplicate.

*** This bug has been marked as a duplicate of bug 481574 ***