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.