SUMMARY Enabling "Additionally include mouse buttons" under "System settings - Application permissions - Legacy X11 App Support" results in X11 apps receinving the clicks and gaining focus unintentionally after virtual desktop switching. STEPS TO REPRODUCE 1. Open an X11 app, I experience this with Google Chrome and Discord. 2. Open System settings and check the "Additionally include mouse buttons". 3. Switch to a different virtual desktop. 4. Use mouse to interact with another X11 app window there, can be window of the same app. Any mouse events sent to X11 window seem to work including mouse move and scrolling. 5. Go back to previous desktop using keybaord shortcuts, I used Meta+Ctrl+Left. It seems important that the cursor is positioned such that it lands on top of a wayland window after virtual desktop switch. Making sure the cursor is also within X11 window bounds seems to help reproduce more reliably. 6. Without moving the cursor away from Wayland window, click in the Setting or or some other wayland app window again. OBSERVED RESULT The click drops right through into the X11 app, the X11 app becomes focused on top of wayland app. EXPECTED RESULT The click does not go through the same way it did not go through before the virtual desktop switching. SOFTWARE/OS VERSIONS KDE Plasma Version: 6.1.2 KDE Frameworks Version: 6.3.0 Qt Version: 6.7.2 ADDITIONAL INFORMATION With focus stealing prevention is set to "High", the X11 app would still get the click although it would not gain focus.
We cannot reproduce using the steps above. If you have any more concrete steps (video?) that could help.
edit, someone just did
*** Bug 497030 has been marked as a duplicate of this bug. ***
*** Bug 498424 has been marked as a duplicate of this bug. ***
(In reply to David Edmundson from comment #1) > We cannot reproduce using the steps above. If you have any more concrete > steps (video?) that could help. In my duplicate bug (Bug #498424), I have attached a video of the problem, if it may help.
I believe the vdesktop switch makes this problem more evident, but it isn't a requirement to reproduce this particular bug. Is this feature intended to capture ALL mouse buttons, such as Left and Right mouse? As far as I know, most people who use this feature use it for Push To Talk in apps like discord or potentially from Chrome, or other similar functionality. Should it exclude buttons like, left mouse button, right, mouse button, mousewheel up, and mousewheel down to prevent focus stealing? Or does it already and somehow focus stealing happens anyways?
The issue is linked to allowing X11 clients sniff keyboard events. If you set the keyboard sniffing policy to "Never", the issue doesn't occur. With the keyboard sniffing policy set to "Never", the X11 client will receive no button press event after switching between virtual desktops. With any other keyboard sniffing policy, the X11 client will receive a button press event. Most toolkits attempt to activate themselves after receiving a button press event. So what happens is that the x11 client receives a button press event, it asks kwin to activate its window, since the event has a valid timestamp and things as such, the activation request should succeed. As the result, the window will also be raised. Not sure if it's an Xwayland bug.
(In reply to Vlad Zahorodnii from comment #7) > The issue is linked to allowing X11 clients sniff keyboard events. If you > set the keyboard sniffing policy to "Never", the issue doesn't occur. Of course, but those of us with it on are using push to talk and similar functionality. > With the keyboard sniffing policy set to "Never", the X11 client will > receive no button press event after switching between virtual desktops. This is true, I was suggesting that perhaps the buttons being sent contribute to the focus stealing, perhaps some buttons are being sent that are not actually being used by users for this functionality. > With any other keyboard sniffing policy, the X11 client will receive a > button press event. Most toolkits attempt to activate themselves after > receiving a button press event. So what happens is that the x11 client > receives a button press event, it asks kwin to activate its window, since > the event has a valid timestamp and things as such, the activation request > should succeed. As the result, the window will also be raised. > > Not sure if it's an Xwayland bug. Do ALL buttons being sent to an app raise focus? Is it only a few buttons like Left, Right Mouse that do this?
> Do ALL buttons being sent to an app raise focus? Is it only a few buttons > like Left, Right Mouse that do this? In case of Qt, all buttons.
I can
For me, a vdesktop switch is not even needed. It just happens if I click onto a window infront of the xwayland one (also sorry for the dupe comment did not mean to send that)
Is there any progress on this issue? This also happen in opensuse tumbleweed
*** Bug 503368 has been marked as a duplicate of this bug. ***
*** Bug 504165 has been marked as a duplicate of this bug. ***
I spent some time looking into this again, but still couldn't figure out a good solution. Let's see if Xwayland developers have any ideas: https://gitlab.freedesktop.org/xorg/xserver/-/issues/1818
(In reply to Andrew from comment #0) I realise that comments can't be modified, but titles can. Considering that this occurs to me despite me never having utilised a virtual desktop in my life, the scope is incorrect.
Changing the title to make it clear it's application focus change that's involved. vdesktop switching isn't necessary to trigger the bug.
A possibly relevant merge request was started @ https://invent.kde.org/plasma/kwin/-/merge_requests/7854
Git commit ed8c663105136790c50df611a0a294fe83c2887f by Xaver Hugl. Committed on 01/07/2025 at 12:44. Pushed by zamundaaa into branch 'master'. xwayland: don't forward left/middle/right mouse buttons to Xwayland They're not used for global shortcuts, and make X11 apps stealing focus on button press much more likely M +5 -0 src/xwayland/xwayland.cpp https://invent.kde.org/plasma/kwin/-/commit/ed8c663105136790c50df611a0a294fe83c2887f
A possibly relevant merge request was started @ https://invent.kde.org/plasma/kwin/-/merge_requests/7855
A possibly relevant merge request was started @ https://invent.kde.org/plasma/kwin/-/merge_requests/7856
Git commit 75ca3e39a1ccb6f168113df0e5f12e3b8369d523 by Xaver Hugl, on behalf of Xaver Hugl. Committed on 01/07/2025 at 14:06. Pushed by zamundaaa into branch 'Plasma/6.4'. xwayland: don't forward left/middle/right mouse buttons to Xwayland They're not used for global shortcuts, and make X11 apps stealing focus on button press much more likely (cherry picked from commit ed8c663105136790c50df611a0a294fe83c2887f) Co-authored-by: Xaver Hugl <xaver.hugl@kde.org> M +5 -0 src/xwayland/xwayland.cpp https://invent.kde.org/plasma/kwin/-/commit/75ca3e39a1ccb6f168113df0e5f12e3b8369d523
Git commit cbe2aa7d71bbb554cd82b7832cee45c7d7afc211 by Xaver Hugl, on behalf of Xaver Hugl. Committed on 01/07/2025 at 14:06. Pushed by zamundaaa into branch 'Plasma/6.3'. xwayland: don't forward left/middle/right mouse buttons to Xwayland They're not used for global shortcuts, and make X11 apps stealing focus on button press much more likely (cherry picked from commit ed8c663105136790c50df611a0a294fe83c2887f) Co-authored-by: Xaver Hugl <xaver.hugl@kde.org> M +5 -0 src/xwayland/xwayland.cpp https://invent.kde.org/plasma/kwin/-/commit/cbe2aa7d71bbb554cd82b7832cee45c7d7afc211
This is not fixed yet, the linked commits just make it less likely to trigger the issue