For the last 10 months I've been encountering seemingly random issue, but I believe I figured out the cause of it now. Whenever application on another virtual desktop demands focus (and manages to actually steal it - forces switch to said virtual desktop - windows programs especially like to do that), then that desktop becomes sort of a "main" one. Effects, animations and auto-hidden panels all work here as expected, but when i switch to another virtual desktop (using the applet or keyboard shortcuts), animations become instant, panels that are auto-hidden (eg. under a window) cannot be popped up, window/desktop overviews like Meta+W, Meta+G, Meta+X, Ctrl+F9/F10 do not open, and KDE's blur effect behind any popup (start, tray, applets, notifs, clipboard) just doesn't exist (fully transparent background, a lot less readable text). This behavior only starts happening after an application forces virt. desktop switch. Every virtual desktop except the "main" one is affected, and you can actually move this "main" status to another virtual desktop if you switch using aforementioned window/desktop overview/pickers (while being on the "main" one, where the keybinds work). Reboot returns everything back to normal. STEPS TO REPRODUCE 1. Open application that can steal focus 2. Switch to a different virtual desktop 3. Wait for application to grab focus and switch virtual screens by itself OBSERVED RESULT Aforementioned affected components now only work on that virtual desktop, and misbehave on other ones. EXPECTED RESULT No changes in behavior. SOFTWARE/OS VERSIONS KDE Plasma Version: 6.6.4 KDE Frameworks Version: 6.25.0 Qt Version: 6.11.0 Kernel Version: 7.0.2-1-cachyos (64-bit) Graphics Platform: Wayland ADDITIONAL INFORMATION I had better-blur installed in the past (taj-ny/kwin-effects-forceblur) before it was discontinued. I do not use it, and iirc the problems were present even before installation. Still, possibly relevant.
Thanks for the bug report. We need a few more details so we can look into this. 1. What applications are you using that steal focus? 2. Can you reproduce this with a brand new user, with the default Breeze theme and all default settings, except the virtual desktop, focus, animation and effects settings? Thanks
(In reply to TraceyC from comment #1) > Thanks for the bug report. We need a few more details so we can look into > this. > > 1. What applications are you using that steal focus? > 2. Can you reproduce this with a brand new user, with the default Breeze > theme and all default settings, except the virtual desktop, focus, animation > and effects settings? > > Thanks Thank you for quick reply. 1. WinSCP seems to be the easiest one to reproduce it with. Another options would be NTE (their launcher kept stealing focus every few minutes), exe version of PuTTY, and similar. 2. I did reproduce it on a newly created user. Apparently, you don't need to get pulled from another virtual desktop - as long as the app calls for focus, it happens. I've been testing thoroughly, changing features one by one, and I've figured out the bug appears after I selected switch animation to Fade. Somehow, that breaks things. When disabled, it returns to normal (until you enable it again). It doesn't seem to be tied with the blur either, it's just one of the things that get affected as a collateral. These are the minimal required settings for bug to occur on a new user (apart from default CachyOS changes): - 2+ virtual desktops, switch effect set to Fade - default blur setting from Breeze is enough to see the change Steps to reproduce: - open WinSCP.exe using "Wine Windows Program Loader" - before it opens, quickly focus another window OR - after it opens, you can try to connect to a nonexistent FTP server, and before it throws an error focus another window (any error message steals focus) - if successful, switching virt. desktops using Ctrl+Meta+arrows or Pager applet should show you all but one virt. desktop is misbehaving.
I can replicate this with WinSCP in Wine. It happens like this: - WinSCP opens some window that isn't actually visible. I didn't look deeper into why exactly, but it doesn't matter that much - that hidden window still gets animated by the open/close and fade desktop effects - since the window is hidden, the animation never progresses - until the fade desktop animation completes, it counts as an active fullscreen effect, which blocks other effects from working This continues even when you close the app, since open/close effects keep deleted windows around until their animation completes... which also never happens.
> that hidden window still gets animated by the open/close and fade desktop effects The window opening animations try to avoid animating hidden windows. Can you please clarify how the window is hidden exactly? Is it that Window::isHidden() == true or something?
WindowItem::isVisible specifically was false, but in the debug console "hidden" was false for the window, so it wasn't visible because of some other reason. I can try debugging it more thoroughly next week.
*** Bug 503615 has been marked as a duplicate of this bug. ***
*** Bug 507541 has been marked as a duplicate of this bug. ***
*** Bug 521208 has been marked as a duplicate of this bug. ***
A possibly relevant merge request was started @ https://invent.kde.org/plasma/kwin/-/merge_requests/9365
Git commit 3d770c8650a70eb2128ee38e89d8360c15b82191 by Vlad Zahorodnii. Committed on 10/06/2026 at 17:52. Pushed by vladz into branch 'master'. Mark X11 windows ready for painting when we start managing or tracking them Technically, the compositor may see the actual window contents slightly later. To handle such a case, kwin sends a sync request. However, it may happen that a window never becomes ready for painting. It can lead to problems if an effect wants to animate such a window. Effects usually reference windows to prevent from getting deleted, and animations are advanced when the window is visible. In other words, kwin will get stuck with a zombie window. There are definitely many options that we could use to address this issue, but most of them will either be too cumbersome or lead to other regressions. On a second look, if we make a window ready for painting right off the bat, it doesn't look that bad. There are no glitchy pixels or anything like that. So this change pivots for that approach. Co-authored-by: Xaver Hugl <xaver.hugl@kde.org> M +0 -4 autotests/integration/dont_crash_aurorae_destroy_deco.cpp M +0 -3 autotests/integration/effects/translucency_test.cpp M +0 -8 autotests/integration/window_rules_test.cpp M +0 -1 autotests/integration/xwayland_dnd_test.cpp M +0 -5 autotests/integration/xwayland_input_test.cpp M +0 -1 autotests/integration/xwayland_selection_test.cpp M +3 -19 src/x11window.cpp https://invent.kde.org/plasma/kwin/-/commit/3d770c8650a70eb2128ee38e89d8360c15b82191
Git commit f038bb7f25d6445d200e4a7a76d203c07fee72a5 by Vlad Zahorodnii. Committed on 10/06/2026 at 18:13. Pushed by vladz into branch 'Plasma/6.7'. Mark X11 windows ready for painting when we start managing or tracking them Technically, the compositor may see the actual window contents slightly later. To handle such a case, kwin sends a sync request. However, it may happen that a window never becomes ready for painting. It can lead to problems if an effect wants to animate such a window. Effects usually reference windows to prevent from getting deleted, and animations are advanced when the window is visible. In other words, kwin will get stuck with a zombie window. There are definitely many options that we could use to address this issue, but most of them will either be too cumbersome or lead to other regressions. On a second look, if we make a window ready for painting right off the bat, it doesn't look that bad. There are no glitchy pixels or anything like that. So this change pivots for that approach. Co-authored-by: Xaver Hugl <xaver.hugl@kde.org> (cherry picked from commit 3d770c8650a70eb2128ee38e89d8360c15b82191) M +0 -4 autotests/integration/dont_crash_aurorae_destroy_deco.cpp M +0 -3 autotests/integration/effects/translucency_test.cpp M +0 -8 autotests/integration/window_rules_test.cpp M +0 -1 autotests/integration/xwayland_dnd_test.cpp M +0 -5 autotests/integration/xwayland_input_test.cpp M +0 -1 autotests/integration/xwayland_selection_test.cpp M +3 -19 src/x11window.cpp https://invent.kde.org/plasma/kwin/-/commit/f038bb7f25d6445d200e4a7a76d203c07fee72a5
*** Bug 520724 has been marked as a duplicate of this bug. ***