SUMMARY Having 2 monitors connected and then a borderless fullscreen application running on each monitor can change alt-tab behaviour and effectively make it non-functional because windows cannot be switched to in certain circumstances as they seem to come to focus "below" the currently shown window I noticed a change in behaviour since 6.6 - this issue definitely didn't occur in 6.5 STEPS TO REPRODUCE 1. Have 2 monitors 2. Open a miscellaneous application on primary monitor 3. Run a borderless fullscreen application on primary monitor (miscellaneous application should now be below this window) 4. Run a borderless fullscreen application on secondary monitor 5. Left click on your mouse into the application running on the secondary monitor (i.e. make the application running on the secondary monitor the current window focus) 6. Now alt tab to the miscellaneous application on the primary monitor OBSERVED RESULT Miscellaneous application does NOT come to the foreground If you left click your mouse into the application running on the primary monitor, then the behaviour reverts back to normal and the miscellaneous application comes to the foreground when alt-tabbing as normal EXPECTED RESULT Miscellaneous application should come to the foreground when your mouse has left clicked into the application on the secondary monitor - i.e. the alt-tab behaviour should not change just because your current window focus is on an application (with the same properties) on another monitor Notice that shortcuts like ctrl + alt + T to open a terminal also suffer the same issue if your window focus is the application on the secondary monitor - the new terminal window opens on the primary monitor but BELOW the primary monitor's active window (and again, alt-tabbing to it does not bring it above the borderless window on the primary monitor). Mouse clicking on the application running the primary monitor brings the behaviour back to normal (as mentioned above) SOFTWARE/OS VERSIONS Operating System: Fedora Linux 43 KDE Plasma Version: 6.6.1 KDE Frameworks Version: 6.23.0 Qt Version: 6.10.2 Kernel Version: 6.18.13-200.fc43.x86_64 (64-bit) Graphics Platform: Wayland ADDITIONAL INFORMATION Same behaviour with Legacy X11 App Support set to disabled
In my case with Plasma 6.6.2 I am able to reproduce this bug using Firefox, SuperTuxKart and Xonotic (SDL) as the "miscellaneous application" and the two borderless fullscreen applications, and all three are Wayland native applications, so I don't think XWayland is the correct component to set for this bug report. In addition, I am also experiencing an issue where if I have a windowed application (for example Dolphin) and a fullscreen application on my second monitor (for example SuperTuxKart), with at least one windowed application on my main monitor (for example Firefox), if the SuperTuxKart is on top in the second monitor then switching to Dolphin using the taskbar in the main monitor requires exactly 3 clicks on Dolphin's taskbar entry, the first click gives Dolphin input focus but it still stays below SuperTuxKart, the second click gives SuperTuxKart focus, and finally the third click brings Dolphin up above SuperTuxKart. All running apps in that scenario are Wayland only too. Someone else I know can also reproduce this variant of the problem with Plasma 6.6.0, and they are certain this did not happen with any previous Plasma version. Given my findings, I'm setting the component to multi-screen since this seems specific to having multiple screens (tried with just one screen and alt-tabbing seems to be fine between fullscreen and windowed applications), and I'm also setting the version first reported in field to 6.6.1 to match the info in the original report.
I tried running a git bisect between KWin 6.5.5 and 6.6.2, which gave me the following output: dd43d93ccf6c4cd8a4f322fd822c98c3d2893c35 is the first bad commit commit dd43d93ccf6c4cd8a4f322fd822c98c3d2893c35 (HEAD) Author: Vlad Zahorodnii <vlad.zahorodnii@kde.org> Date: Mon Oct 13 17:02:48 2025 +0300 Make Workspace::windowActivated() signals more reasonable If workspace()->activateWindow() is called and there is another active window, the following signal sequence will be observed: - Workspace::windowActivated(nullptr) - Workspace::windowActivated(anotherWindow) The windowActivated() signal with nullptr window is unexpected. This change also untangles the dependency order between Window::setActive() and Workspace::setActiveWindow(). Fullscreen related code has been removed from Workspace::setActiveWindow() because it matches the logic in Window::setActive(). src/activation.cpp | 22 ++++++---------------- src/events.cpp | 8 +++++--- src/layershellv1window.cpp | 2 +- src/window.cpp | 1 - src/xdgshellwindow.cpp | 2 +- 5 files changed, 13 insertions(+), 22 deletions(-) Unfortunately reverting the above commit on KWin 6.6.2 doesn't work due to conflicts, but I can confirm that both the issue in the original report and the other variant of the issue I encountered in comment 1 disappears if I build KWin at the point right before the above commit, and that both issues appear if I rebuild KWin with that commit added. Both issues are also present in KWin git master at commit 8a5d6d97e729cbcdd2ac3f25b913a2f593712b01 dated Mon Mar 9 01:49:54 2026 UTC time.
What do you mean by "borderless fullscreen application"? Can you provide a screenshot or a screencast showing how to reproduce the issue?
Created attachment 190527 [details] Recording of the issue using OBS, SuperTuxKart and Xonotic "Borderless fullscreen" is a term used by some Windows games to differentiate that option from the classic "exclusive fullscreen". The latter tries to take over the whole screen (making switching between windows no longer work at least on Windows) and changes the screen resolution to whatever the game wants (applies to both Windows and X11), while the former just creates a window with no borders and the same size as the screen. I think "borderless fullscreen" is pretty much what all Wayland apps are stuck with anyway if I'm not mistaken, so I believe any "fullscreen" application qualifies on Wayland. I did try using Firefox's fullscreen mode (the one from pressing F11) and it too can trigger this bug. Anyway, I have attached a screen recording showing the issue reported in the original report, where I have OBS Studio as the "miscellaneous application" that is not fullscreen, as well as SuperTuxKart and Xonotic (SDL) as the two fullscreen applications. OBS and SuperTuxKart are in one screen and Xonotic is in the other, and while the mouse remains in the Xonotic screen I am unable to use Alt+Tab to get OBS to appear above SuperTuxKart. I am only able to reach OBS when I move the mouse over to the SuperTuxKart screen. For the sake of reproduction just three Firefox windows seems to work too, with one windowed instance and two fullscreen instances to replace OBS Studio, SuperTuxKart and Xonotic respectively.
Based on the commit posted by Prajna https://github.com/KDE/kwin/commit/dd43d93ccf6c4cd8a4f322fd822c98c3d2893c35#diff-bd8da48fe5c152b894e487663ce4b14d2b2657980daf82f2ecb7328c38def6eb Seems restoring the lines 254-262 on activation.cpp solves the issue for me at least Please try // activating a client can cause a non active fullscreen window to loose the ActiveLayer status on > 1 screens if (outputs().count() > 1) { for (auto it = m_windows.begin(); it != m_windows.end(); ++it) { if (*it != m_activeWindow && (*it)->layer() == ActiveLayer && (*it)->output() == m_activeWindow->output()) { (*it)->updateLayer(); } } }
similar tickets: https://bugs.kde.org/show_bug.cgi?id=484155 and https://bugs.kde.org/show_bug.cgi?id=517224
The fix for bug 484155 also fixes the two versions of the issues I ran into here, with borderless fullscreen windows covering both of my screens I am now able to reach non-fullscreen applications via Alt+Tab, and I can get to a non-fullscreen app behind a fullscreen one with just one click on the relevant taskbar entry, so I think setting this bug to be a duplicate of 484155 makes sense since the root cause seems to be the same (fullscreen windows staying on top even when not focused). Either that or this should be kept separate but fixed with the same commit, someone else can change the status if they disagree. *** This bug has been marked as a duplicate of bug 484155 ***