SUMMARY Some windows stopped being focussed/raised after upgrading to 6.4.90 (in 6.4.5 this still worked without any change in settings). I personally can consistently reproduce this with polkit dialogs (example seen here: https://youtu.be/5Y8XCpnnUl0) and when launching Vesktop from the application launcher. Focus stealing prevention is set to "medium" which - as far as I know - should automatically raise those windows when they're spawned. STEPS TO REPRODUCE 1. In a terminal execute `pkexec echo` OBSERVED RESULT The polkit dialog appears in the task manager but the window is not raised. EXPECTED RESULT The window should be raised (at least on "medium" focus stealing prevention). SOFTWARE/OS VERSIONS Operating System: Gentoo 2.18 KDE Plasma Version: 6.4.90 KDE Frameworks Version: 6.18.0 Qt Version: 6.10.0 Kernel Version: 6.17.0-rc7-cachyos (64-bit) Graphics Platform: Wayland Processors: 32 × AMD Ryzen 9 7950X3D 16-Core Processor Memory: 64 GiB of RAM (62.5 GiB usable) Graphics Processor: Intel® Arc Manufacturer: ASUS ADDITIONAL INFORMATION - I'm currently running the Qt 6.10.0 RC but the same issue existed with 6.9.2 - The system I'm using is compiled with LLVM (and their libc++)
I am unable to repro this Operating System: Fedora Linux 42 KDE Plasma Version: 6.5.80 KDE Frameworks Version: 6.19.0 Qt Version: 6.9.2 Kernel Version: 6.16.8-200.fc42.x86_64 (64-bit) Graphics Platform: Wayland Processors: 12 × AMD Ryzen 5 3600 6-Core Processor Memory: 16 GiB of RAM (15.5 GiB usable) Graphics Processor: AMD Radeon RX 6600
Oh nevermind I'm dumb. I had the prevention set to "low" instead of "medium" Can confirm after all.
The default is Low. Can confirm the issue with it set to Medium.
> In a terminal That's expected, see https://invent.kde.org/plasma/kwin/-/issues/290 About Vesktop, that means it's neither activating itself nor setting the app id properly (we have a heuristic for activation if the app id matches the app you started). The former issue is a Chromium / Electron thing, which is being fixed upstream, the latter is something Vesktop needs to fix, so please report that to the app.
> That's expected, see https://invent.kde.org/plasma/kwin/-/issues/290 Hmm interesting - I just noticed the behaviour change compared to 6.4 where things like those polkit dialogs would just get raised anyway. Might just go back to "low" focus stealing prevention then. > we have a heuristic for activation if the app id matches the app you started Thanks for the pointer - that seems to be the issue. Although it's more likely Gentoo packaging a bad .desktop file that doesn't match the ID Vesktop sets.
I am noticing this on yakuake - on 6.4.5 and medium focus stealing, it drops down over other programs. On 6.5 it doesn't.
*** Bug 511050 has been marked as a duplicate of this bug. ***
I'm seeing this with ksshaskpass in 6.5, exactly the behaviour shown in OP's video, which is a serious problem because it's how I authenticate for sudo: sudo uses pam_ssh_auth, which contacts the ssh-agent, which prompts the user to confirm usage of the key... Except now the prompt has to be manually raised.
*** Bug 511015 has been marked as a duplicate of this bug. ***
*** Bug 511098 has been marked as a duplicate of this bug. ***
Don't know if I should open a different bug report but the issue might be a bit larger. Affects all/most GTK apps and core parts of the OS too. Issue 1: The "leave" menu brought about using ctrl+alt+del doesn't get focus. Steps to reproduce: - Set focus stealing prevention to medium - Open a window and keep it in focus (tried with Firefox and Dolphin). - ctrl+alt+del to bring up "leave" menu - menu is not navigable by keyboard. Typing something actually brings up krunner in the background behind the blurred "Leave" menu Issue 2: Password prompts for KDE Vault or new WiFi connection opened after clicking through buttons on the system tray don't steal focus. Steps to reproduce: - Set focus stealing prevention to medium - Try to unlock a previously created and locked vault on KDE Vault - The prompt to enter password appears but doesn't steal focus. Must manually click in password box before entering. Issue 3: New windows for GTK apps don't open in front. Not observed in QT apps (Tested Dolphin and Konsole) Steps to reproduce: - Set focus stealing prevention to medium - Open any GTK app window (Tested Firefox, Libreoffice, Xournal and PDF Arranger) - Open new window of the same app (often ctrl+n shortcut) - New window opens behind first window Workaround: All issues fixed by setting focus prevention to Low. I understand Low is supposed to be default, but the focus prevention should not be so intense on Medium. Also didn't notice this till recently so something changed. Also the issue with the GTK apps is the inconsistency between GTK apps and QT apps.
(In reply to Shariar Rahman from comment #11) > Issue 1: The "leave" menu brought about using ctrl+alt+del doesn't get focus. > > Steps to reproduce: > - Set focus stealing prevention to medium > - Open a window and keep it in focus (tried with Firefox and Dolphin). > - ctrl+alt+del to bring up "leave" menu > - menu is not navigable by keyboard. Typing something actually brings up > krunner in the background behind the blurred "Leave" menu The logout greeter is started as a new process, it should be able to get activation through the shortcut... It currently doesn't show up at all in my dev session, so someone else will need to take a closer look at it. > Issue 2: Password prompts for KDE Vault or new WiFi connection opened after > clicking through buttons on the system tray don't steal focus. > > Steps to reproduce: > - Set focus stealing prevention to medium > - Try to unlock a previously created and locked vault on KDE Vault > - The prompt to enter password appears but doesn't steal focus. Must > manually click in password box before entering. That one is known. The network manager ones are especially annoying, because we don't open the window directly, rather it's NetworkManager just prodding things from the background. > Issue 3: New windows for GTK apps don't open in front. Not observed in QT > apps (Tested Dolphin and Konsole) > > Steps to reproduce: > - Set focus stealing prevention to medium > - Open any GTK app window (Tested Firefox, Libreoffice, Xournal and PDF > Arranger) > - Open new window of the same app (often ctrl+n shortcut) > - New window opens behind first window Firefox is already fixed upstream, but for normal GTK apps this needs to be reported to GTK. > I understand Low is supposed to be default, but the focus prevention should > not be so intense on Medium. Unfortunately the status quo is that many apps don't activate windows at all, or do it only in a broken way - and aside from some heuristics to work around broken apps in some situations (which we do on medium), the only thing that could be done is to unconditionally give new windows focus.
(In reply to Zamundaaa from comment #12) > The logout greeter is started as a new process, it should be able to get > activation through the shortcut... It currently doesn't show up at all in my > dev session, so someone else will need to take a closer look at it. Thank you - this was my main issue. I honestly don't even know when or how I (probably) set focus stealing prevention to Medium. Issue only came up with 6.5. I've se the focus stealing prevention to low for now. > That one is known. The network manager ones are especially annoying, because > we don't open the window directly, rather it's NetworkManager just prodding > things from the background. This one can be an annoyance. I'm sure a solution will be found eventually. > Unfortunately the status quo is that many apps don't activate windows at > all, or do it only in a broken way - and aside from some heuristics to work > around broken apps in some situations (which we do on medium), the only > thing that could be done is to unconditionally give new windows focus. Understandable. Thank you all the same.
*** Bug 511283 has been marked as a duplicate of this bug. ***
(In reply to Zamundaaa from comment #12) > (In reply to Shariar Rahman from comment #11) > > Issue 1: The "leave" menu brought about using ctrl+alt+del doesn't get focus. > > > > Steps to reproduce: > > - Set focus stealing prevention to medium > > - Open a window and keep it in focus (tried with Firefox and Dolphin). > > - ctrl+alt+del to bring up "leave" menu > > - menu is not navigable by keyboard. Typing something actually brings up > > krunner in the background behind the blurred "Leave" menu > The logout greeter is started as a new process, it should be able to get > activation through the shortcut... It currently doesn't show up at all in my > dev session, so someone else will need to take a closer look at it. > > > Issue 2: Password prompts for KDE Vault or new WiFi connection opened after > > clicking through buttons on the system tray don't steal focus. > > > > Steps to reproduce: > > - Set focus stealing prevention to medium > > - Try to unlock a previously created and locked vault on KDE Vault > > - The prompt to enter password appears but doesn't steal focus. Must > > manually click in password box before entering. > That one is known. The network manager ones are especially annoying, because > we don't open the window directly, rather it's NetworkManager just prodding > things from the background. > > > Issue 3: New windows for GTK apps don't open in front. Not observed in QT > > apps (Tested Dolphin and Konsole) > > > > Steps to reproduce: > > - Set focus stealing prevention to medium > > - Open any GTK app window (Tested Firefox, Libreoffice, Xournal and PDF > > Arranger) > > - Open new window of the same app (often ctrl+n shortcut) > > - New window opens behind first window > Firefox is already fixed upstream, but for normal GTK apps this needs to be > reported to GTK. > > > I understand Low is supposed to be default, but the focus prevention should > > not be so intense on Medium. > Unfortunately the status quo is that many apps don't activate windows at > all, or do it only in a broken way - and aside from some heuristics to work > around broken apps in some situations (which we do on medium), the only > thing that could be done is to unconditionally give new windows focus. How would an app activate itself when its tray icon (or tray icon context menu action) is clicked? It doesn't receive an activation token like it does when e.g. notification is clicked, and it can't request a token from compositor because it's not in focus at that moment.
(In reply to equeim from comment #15) > How would an app activate itself when its tray icon (or tray icon context > menu action) is clicked? It doesn't receive an activation token like it does > when e.g. notification is clicked, and it can't request a token from > compositor because it's not in focus at that moment. It does receive an activation token when you click the tray icon, but activating from the context menu is indeed still broken. If you're interested in fixing it, https://invent.kde.org/plasma/kwin/-/issues/186 has a few people in it that know more about SNI than I do and may be able to give some pointers for where to look.
A possibly relevant merge request was started @ https://invent.kde.org/plasma/plasma-workspace/-/merge_requests/5957
Actually, I just looked a bit at plasma workspace code myself, and figured out how to fix that case :)
(In reply to Zamundaaa from comment #16) > (In reply to equeim from comment #15) > > How would an app activate itself when its tray icon (or tray icon context > > menu action) is clicked? It doesn't receive an activation token like it does > > when e.g. notification is clicked, and it can't request a token from > > compositor because it's not in focus at that moment. > It does receive an activation token when you click the tray icon, but > activating from the context menu is indeed still broken. > > If you're interested in fixing it, > https://invent.kde.org/plasma/kwin/-/issues/186 has a few people in it that > know more about SNI than I do and may be able to give some pointers for > where to look. Thanks, I didn't know it was already supported by the protocol. > Actually, I just looked a bit at plasma workspace code myself, and figured > out how to fix that case :) It actually doesn't work for direct clicks on tray icon either, when using Qt apps that make use of QSystemTrayIcon. I think I figured it out why: Inside KDE session Qt apps use KDE's platform integration plugin which provides its own QSystemTrayIcon implementation that goes through KStatusNotifierItem. KStatusNotifierItem supports SNI's ProvideXdgActivationToken method, and it is implemented through KWindowSystem::setCurrentXdgActivationToken(). However, KWindowSystem's window activation mechanism is not integrated with Qt's built-in xdg-activation support (that was added in Qt 6.5 IIRC) and so when application code shows the window on QSystemTrayIcon::activated signal, activation doesn't happen. KWindowSystem::setCurrentXdgActivationToken only sets its own internal state which Qt doesn't know about (https://github.com/KDE/kwindowsystem/blob/5d038c249493ef3704a3ee3599634b8ca711a8f0/src/platforms/wayland/windowsystem.cpp#L103C20-L103C35). Qt's own mechanism works by setting XDG_ACTIVATION_TOKEN env variable that's automatically read from (and cleared) when a window is shown.
If you run a Qt app in KDE with XDG_CURRENT_DESKTOP and KDE_FULL_SESSION env variables unset which prevents Qt from loading KDE platform theme plugin, the window activation by clicking on tray icon starts to work. That's because Qt's own implementation of SNI for QSystemTrayIcon also supports ProvideXdgActivationToken and it sets XDG_ACTIVATION_TOKEN env variable: https://github.com/qt/qtbase/blob/12313f3ebe00808e9b1c27ddcb49cedf3e09582b/src/gui/platform/unix/dbustray/qstatusnotifieritemadaptor.cpp#L140 KWindowSystem's window activation machinery can probably be removed (at least partially?) since Qt already supports xdg-activation.
A possibly relevant merge request was started @ https://invent.kde.org/frameworks/kwindowsystem/-/merge_requests/194
Git commit 48ec9f56965d95ec429704d6a4b98865d8c7c39a by Vlad Zahorodnii, on behalf of Alexey Rochev. Committed on 15/11/2025 at 09:28. Pushed by vladz into branch 'master'. Use XDG_ACTIVATION_TOKEN env variable for setCurrentXdgActivationToken() Qt's built-in window activation mechanism reads this env variable when window is shown. Set it so that Qt can use it. Also use in our activateWindow() to match Qt's behaviour. M +10 -3 src/platforms/wayland/windowsystem.cpp M +1 -1 src/platforms/wayland/windowsystem.h https://invent.kde.org/frameworks/kwindowsystem/-/commit/48ec9f56965d95ec429704d6a4b98865d8c7c39a
Git commit c7bf930539226ae76c547d2d495d73b1b6de3797 by Xaver Hugl. Committed on 18/11/2025 at 15:04. Pushed by zamundaaa into branch 'master'. applets/systemtray: send activation token for context menu actions too This allows apps to activate their windows when the user clicks "restore" in the context menu, rather than only when the icon itself is clicked. M +19 -2 applets/systemtray/statusnotifieritemsource.cpp M +6 -1 libdbusmenuqt/dbusmenuimporter.cpp M +8 -1 libdbusmenuqt/dbusmenuimporter.h https://invent.kde.org/plasma/plasma-workspace/-/commit/c7bf930539226ae76c547d2d495d73b1b6de3797
*** Bug 512640 has been marked as a duplicate of this bug. ***