SUMMARY On my triple monitor setup, when trying to alt+tab, metakey or any other kwin shortcut, it will not perform it. There are a couple of scenarioes where this happens; 1. Moving the mouse over the screen B (which is not in focus) and trying to alt+tab, this is while an x11-wayland-bridge program is running in fullscreen (borderless-fullscreen), alt+tab does not work until the third or fourth input of it. It is clear that the action of the alt+tab was commited, since the window to change window did show and does show that the application in the background should be in the front, but the program running in fullscreen is still on top. All of this CAN be avoided if I press the program which is in fullscreen, thereby switching the focus to that monitor and letting kwin do its thing normal, but if I only just hover my mouse over to that monitor the bug persists. 2. On monitor A,B or even C, if a program shown via the x11-wayland-bridge OR regular wayland is in fullscreen, then no shortcut works at all. In this case, it is worth to note in which programs this has happened. In the first case, noted as 1. above, we are talking about Plane 9 running on wine 10.14. But in this instance, 2., we are talking about Firefox videoplayer fullscreen and Discord fullscreen on screenshare. In this case inputs only work if either A: exit fullscreen via button provided by the software or B: keep repeating the metakey or alt+tab until it works, the number of button presses seems to be random and sometimes option A is the only way out of a fullscreen window. STEPS TO REPRODUCE 1. Switch focus (with seperate screen focus enabled) by moving the mouse to monitor B from A while something is in fullscreen on monitor B. 2. Try to use any global shortcut (alt+tab, krunner, metakey, etc). 3. Global shortcut commences but fullscreen window is still above everything else. OBSERVED RESULT The fullscreen window, no matter the monitor or windowtyp (x11/Wayland), stays on top without any change. EXPECTED RESULT The fullscreen window goes behind the taskbar if the metakey is pressed or the window is switched to the correct one if alt+tab is pressed. SOFTWARE/OS VERSIONS Linux/KDE Plasma: Arc Linux KDE Plasma Version: 6.6.2 KDE Frameworks Version: 6.23.0 Qt Version: 6.10.2 ADDITIONAL INFORMATION I could not find a report like this, so I filed one but I did find a reddit question about it; https://www.reddit.com/r/kde/comments/1rl4u2a/anyone_else_having_focus_issues_with_kde_66_and/
Extra note; this started if the 6.6 update.
Thanks for the detailed bug report. So that we can try to reproduce this, can you please share a screenshot of System Settings - Window Behavior - Focus Thanks
Created attachment 190609 [details] Focus screen page, swedish
Created attachment 190610 [details] Focus screen page, auto translated
Hello, I'm affected by this as well. It seems to only have regressed since 6.6 Window Focus settings are all default. I've managed to reliably reproduce this and the steps are below: Prerequisite: Two Monitors 1. Launch Plasma System Settings application on Monitor 1 - keep open 2. Launch a fullscreen app on Monitor 1 also - in this instance i just started playing a video file with MPV and fullscreened it (system settings should now be below the fullscreen app) 3. Move your cursor and click anywhere on Monitor 2 (I just clicked the blank desktop) 4. ALT + TAB to System Settings application (you can also use META + W for overview to switch to system settings) 5. Observe the window does not focus and still to be buried behind the fullscreen application Similarly, if you click back to Monitor 1 and Alt tab to the app, the app will focus correctly.
Thanks to both of you for the extra details, that's very helpful. Following Justin's steps to reproduce, I am able to reproduce the bug on Plasma 6.6.3 / KF 6.24.0 as well as on Plasma built from git-master
(In reply to TraceyC from comment #6) > Thanks to both of you for the extra details, that's very helpful. > Following Justin's steps to reproduce, I am able to reproduce the bug on > Plasma 6.6.3 / KF 6.24.0 as well as on Plasma built from git-master Hey Tracey, I’ve noticed some additional behaviour that seems related potentially to the same root cause but may help narrow this down. Using the same reproduction setup, this also affects window dragging. If I’m focused on Monitor 2 (with a fullscreen application on Monitor 1) and drag a window from Monitor 2 over to Monitor 1 (using META + LEFT CLICK Drag), I would expect the dragged window to appear above the fullscreen application while moving it. However, as soon as the window crosses over to Monitor 1, the window is not raised while dragging and buries behind the fullscreen app. Once I release the drag, it then shows the window as focusd. This makes it difficult to accurately position the window, since it’s no longer visible once it crosses onto the monitor with the fullscreen app. Would you prefer that I keep this information in this report, or should I open a separate ticket for it, even if it may share the same underlying cause? Also just wanted to ask is there anything else you may need from me to help get a resolution for this sooner? Thanks again!
> Using the same reproduction setup, this also affects window dragging. If I’m > focused on Monitor 2 (with a fullscreen application on Monitor 1) and drag a > window from Monitor 2 over to Monitor 1 (using META + LEFT CLICK Drag), I > would expect the dragged window to appear above the fullscreen application > while moving it. However, as soon as the window crosses over to Monitor 1, > the window is not raised while dragging and buries behind the fullscreen > app. Once I release the drag, it then shows the window as focusd. > > This makes it difficult to accurately position the window, since it’s no > longer visible once it crosses onto the monitor with the fullscreen app. This was 100% an issue prior to the focus bug raised here - I remember it well, it just never really bothered me
Is there a known solution to this yet? I have also been affected since KDE 6.6 on Fedora (it's not just Arch).
*** This bug has been marked as a duplicate of bug 484155 ***