KDE Plasma: Mouse clicks are registered on the wrong workspace

Wild Penguin · 2025-02-24 18:33:27

Hi,

I use different workspaces a lot and switch between them along with 6 virtual desktops. This issue has to do with changing workspaces (not virtual desktops, this is an important distinction!). This is on X.Org.

After recently (a week or so), there's this weird focus issue. All mouse clicks are registered on a window which is on a workspace from which I've just switched out of. I can see this by the fact that the mouse cursor changes to different types (such as text input / caret cursor, finger for links etc.) depending on the window on the other workspace, not the window I'm looking at, and the window I'm actually looking at does not react at all. It can be confusing and seem like the application has hung. But after switching the workspace back, the window on the other workspace has reacted to my clicks.

Anyone seen or experiencing anything similar?

I'm sorry if what I've described above is difficult to understand, it's a really peculiar and weird bug, and it's difficult to explain what is going on. Perhaps I should capture a video to demonstrate. It doesn't happen always but often enough that it's annoying, but should be somewhat easy to reproduce.

After switching back-and-forth a time or two, the focus usually starts to behave (until it randomly breaks again). But you can imagine it's quite annoying and obviously can cause unintentional/erroneous input in the window receiving the clicks, and in worst-case-scenario, data loss etc.

I'm not sure but I also believe keyboard input is going to the other window (on the other workspace). I've been a bit hesitant on testing since I'm actually trying to get work done and don't want to send keystrokes blindly to some application I'm actually trying to do some productive work with.

(perhaps I should start a session for the sole purpose to reproduce this bug, capture a video, take logs etc.)

Cheers!

Last edited by Wild Penguin (2025-02-24 18:35:25)

V1del · 2025-02-27 20:25:38

If I'm reading the changelog right this might be fixed in 6.3.2 https://bugs.kde.org/show_bug.cgi?id=500529 (yes I know this talks about virtual desktops, but the underlying change is in workspace.cpp)

A missed the on xorg bit so maybe not...

Last edited by V1del (2025-02-27 20:41:25)

galdre · 2025-03-22 01:51:44

I just updated today for the first time in a couple of weeks and it's happening constantly to me. Incredibly frustrating. I'm on KDE/Wayland.

seth · 2025-03-22 07:25:50

Since there's no input redirection on X11 and a stale grab would not be passed around, suspending the compositor would reveal whether the actual problem is that it renders the wrong set of windows (ie un/mapping failed)

For wayland, see the linked bug and check whether the affected clients are indeed all running on xwayland, https://wiki.archlinux.org/title/Waylan … plications

Wild Penguin · 2025-04-04 18:55:39

Since there's no input redirection on X11 and a stale grab would not be passed around, suspending the compositor would reveal whether the actual problem is that it renders the wrong set of windows (ie un/mapping failed)

I believe this (rendering wrong set of windows) can not be the case, since what I'm seeing is what I'd expect when using the UI. So it can not be drawing the wrong set of windows (unless I've mistaken what you've meant). But I could try suspending the compositor as it's easy, however I think I've seen this even when running games which I've set up so that the compositor is suspended while a full-screen game is running.

This is still occurring as of today, indeed very frustrating, distracting and causing all kinds of unintended clicks.

Wild Penguin · 2025-04-04 19:02:01

Actually, I just tried this without the compositor and noticed something I have not seen before.

With a compositor on, changing the virtual desktop and/or workspace is reflected and the right windows (what I'd expect to see) are rendered.

However, with compositor off, the desktop and the workspace changes but sometimes a window will follow to to the wrong desktop. Now I can see where the click end up. The windows does not permanently "change workspace", for example re-toggling compositor (ALT+SHIFT+F12) makes it move to it's rightful place. So seth is right after all.

In other words: The bug can be reproduced with or without compositor, but the only difference is that without compositor I can actually "see the wrong window following around to the wrong desktop", but with compositor I can not see it (but it still receives the input).

It's really odd and weird behavior, and difficult to describe! Perhaps I should really indeed make a video of it.

Last edited by Wild Penguin (2025-04-04 19:02:55)

seth · 2025-04-04 20:14:51

It would seem that the window gets wrongfully mapped (by kwin?) but even the compositor (kwin!) isn't aware of that (where typically it should intercept mapping events and include the window)

=> There's a kwin bug, it either wrongly maps a window and also ignores in the compositor that or simply ignores that a window gets mapped.
(It's more likely that kwin also does the wrong mapping, because it's principally responsible for that on workspace changes and it would explain the compositor as related bug for some in-process lock)

Any idea what might be special about the window that "follows to to the wrong desktop"?
I wonder whether maybe some (mouse) grabbing condition could be at play here - is it related to popup menus (the rightclick stuff or from a menubar) or drag-and-drop actions?

Wild Penguin · 2025-04-14 20:58:24

I don't know what is the trigger. I do not drag-and-drop nor use context menus that much. It's mostly happening with Firefox windows but that is probably just because I mostly have Firefox windows open, it happens with other applications, too.

It happens just with regular clicks and changing the workspace, I'm not doing anything "special" (such as DnD or context menus, for lack of a better word).

seth · 2025-04-15 06:53:08

There's this weird thing here going on: https://bbs.archlinux.org/viewtopic.php?id=304839
FF probably uses HW acceleration what might or not qualify it as "opengl window" - have you ever *triggered* this w/ the compositor off?

Have you btw. filed a bug at https://bugs.kde.org/ ?

Wild Penguin · 2025-04-21 19:50:57

No, I have not filed a bug report, I've been too busy recently.

Yes, I have triggered this with the compositor off as I described in post #6 - it behaves the same but I can actually see what is going on (window is following around to wrong workspaces).

This is not FF specific, I can definitely reproduce this with other applications.

seth · 2025-04-22 07:08:11

(Wasn't sure whether you had not just toggled it off to inspect the situation)
You'll have to file a bug, there's (most likely) some race condition around event handling (there's a feature/shortcut to take the window to the other workspace and that might get triggered accidentally and w/o the WM noticing, so bug there, not in your fingers) - those are hard to find and the devs will have the best idea where to look for it.

LANNOCC · 2025-07-21 17:46:12

I just wanted to chime in to add that I am also affected by this issue after a recent KDE Plasma upgrade. I'm on Gentoo, however, so this isn't specific to Arch. So far, this forum is the only place I can currently find a report about it.

LANNOCC · 2025-07-21 17:56:29

Found it: https://bugs.kde.org/show_bug.cgi?id=503962

LANNOCC · 2025-07-28 15:38:39

I just upgraded KDE to 6.3.6 and I am no longer affected by the problem. Seems like it is fixed!

Arch Linux

#1 2025-02-24 18:33:27

KDE Plasma: Mouse clicks are registered on the wrong workspace

#2 2025-02-27 20:25:38

Re: KDE Plasma: Mouse clicks are registered on the wrong workspace

#3 2025-03-22 01:51:44

Re: KDE Plasma: Mouse clicks are registered on the wrong workspace

#4 2025-03-22 07:25:50

Re: KDE Plasma: Mouse clicks are registered on the wrong workspace

#5 2025-04-04 18:55:39

Re: KDE Plasma: Mouse clicks are registered on the wrong workspace

#6 2025-04-04 19:02:01

Re: KDE Plasma: Mouse clicks are registered on the wrong workspace

#7 2025-04-04 20:14:51

Re: KDE Plasma: Mouse clicks are registered on the wrong workspace

#8 2025-04-14 20:58:24

Re: KDE Plasma: Mouse clicks are registered on the wrong workspace

#9 2025-04-15 06:53:08

Re: KDE Plasma: Mouse clicks are registered on the wrong workspace

#10 2025-04-21 19:50:57

Re: KDE Plasma: Mouse clicks are registered on the wrong workspace

#11 2025-04-22 07:08:11

Re: KDE Plasma: Mouse clicks are registered on the wrong workspace

#12 2025-07-21 17:46:12

Re: KDE Plasma: Mouse clicks are registered on the wrong workspace

#13 2025-07-21 17:56:29

Re: KDE Plasma: Mouse clicks are registered on the wrong workspace

#14 2025-07-28 15:38:39

Re: KDE Plasma: Mouse clicks are registered on the wrong workspace

Board footer