SUMMARY When using the "Window rules" system the "Focus stealing prevention" setting is not enforced for native Wayland windows even at the "Force->Extreme" level. Seems to be working fine for the legacy X11 windows like XTerm. STEPS TO REPRODUCE 1. Make sure you are running under a Wayland session 2. Make a window rule for a native Wayland application (like Alacritty) 3. In the rule set the "Focus stealing prevention" to "Force" & "Extreme" 4. Apply the rule 5. Follow the steps 2-4. this time for a legacy X11 application (like XTerm) OBSERVED RESULT When new Wayland window is created it get the focus (every time) no matter the rules set. X11 applications follow the window rules so (in the example above) new XTerm windows don't steal the current focus. EXPECTED RESULT Being able to prevent focus stealing (or maybe more specifically: stealing focus on window creation) even for native Wayland applications. Can supply many use cases on request. SOFTWARE/OS VERSIONS Linux/KDE Plasma: Fedora release 40 (Forty) KDE Plasma Version: 6.0.5 KDE Frameworks Version: 6.2.0 Qt Version: 6.7.1 ADDITIONAL INFORMATION - Tested that other parts of the rule are being applied (so the rule itself is active) - Using the "Focus follows mouse" windows activation policy by default, but tested with "Click to focus" as well and no difference.
Additional note: Focus stealing prevention seem to be working for Wayland windows when set globally (set Window Management -> Window Behavior -> Focus -> Focus stealing prevention to "Extreme"). There just currently doesn't seem to be a way to make rules for individual applications/windows using the "Window Rules" -> [rule] -> "Focus stealing prevention" & "Focus protection" features (either way, whatever the default).
This was intentional, wayland till relatively recently had no way to "correctly" pass focus and no-one does it on launch. So any focus stealing prevention becomes never giving it focus on launch, which is also different from what the setting would do on X. Making it so rules apply for /just/ extreme is doable, so I'll put this as confirmed. Being on the same level as X simply isn't.
It is my understanding that Wayland applications have no mechanism to switch focus themselves. That being said, kwin probably should have the ability to define if certain application/window should get the focus initially and I personally find it quite an essential feature. The question of whether it should still be called "Focus stealing prevention" or (for example) "Initial focus" is valid, but regardless it would be really nice to have some mechanism in place. I can see at least two possible levels for this setting (not sure how well they map to the current "Focus stealing prevention" levels): a) New window never gets focus b) New windows only gets focus if no other window has one , but would be perfectly happy if just the b) option was implemented. Behaviour when window is spawned in a different Workspace/Activity should also be considered. Here are a few use cases: 1) "Cautious / security conscious user" - no new windows should get focus initially, except for a few well defined ones (like a terminal app or KRunner) 2) "Long startup time apps" - define a rule that a specific application that has a very long startup time should not get the initial focus (breaks workflow) 3) Rules for specific "remotely controlled" GUI apps - For example media player controlled from the terminal script. And a few other related notes (just spit balling here): - It would be also nice to have the ability to define a global rule in a form of: "Don't get initial focus if startup time is longer than X" - Probably a pipe dream, but being able to distinguish between application launches initiated directly by user (terminal/KRunner/start menu) VS ones initiated by other applications could be very useful too.
(In reply to Vaclav Fiala from comment #3) > Here are a few use cases: > 1) "Cautious / security conscious user" - no new windows should get focus > initially, except for a few well defined ones (like a terminal app or > KRunner) > 2) "Long startup time apps" - define a rule that a specific application that > has a very long startup time should not get the initial focus (breaks > workflow) Can confirm these problems/desires, although I'm not sure the proposed approaches are the right ones: 1) User interaction is what should matter, a whitelist would be just a flawed workaround. If I press Ctrl-Alt-T I surely want Konsole right in my face, but if a background program would start it for some odd reason, I definitely wouldn't want it to steal focus. 2) Would have to test to get a feel, but I'm not sure I'd want a timeout in that case. If I wait for the launch then it should get focus anyway, but if I focus on another window while the program is starting, then I'd be okay with it not getting focus, no matter how fast it starts. The potentially tricky problem is starting from KRunner or the the Application Launcher as focus goes back to the previous window on those cases, and it's not obvious if the user wants to keep it that way which is the case where I could see the timeout making sense, although I still wouldn't be a fan of the resulting inconsistency. I'm not on Plasma 6 yet, so can't test current behavior, but so far I just gave up on the focus stealing prevention setting. Too low and silly programs pop up windows while I'm typing, potentially accepting a call almost instantly when hitting enter for what should be a new line in a text editor, or too extreme and even child windows appear behind the parent window. Speaking of security though, there's another important aspect other than accidental actions taken as mentioned. Ideally one day we are going to get the "promised" Wayland clipboard security feature which prevents programs just reading the clipboard whenever they feel like, even if that's an optional setting for more secure environments. This requires focus stealing prevention to work properly, so there's no unavoidable accidental user interaction which would allow clipboard reading (although I would opt into a strict Ctrl+(Shift)+V only pasting security level if ever available). GNOME had something relevant, and wl-paste worked around it with focus stealing: https://github.com/bugaevc/wl-clipboard/issues/31#issuecomment-462023847
> Ideally one day we are going to get the "promised" Wayland clipboard > security feature which prevents programs just reading the clipboard whenever > they feel like, even if that's an optional setting for more secure > environments. The clipboard situation might be actually a little bit worse on Wayland then on X11. On X11 an application operating on sensitive data (like a password manager), could insert the password directly by emulating keyboard events instead. No such option on Wayland by design (there is ydotool which circumvents this, but you probably lose a lot of other nice security properties when you install it). Then again, on X11 pretty much any app could read all the keyboard events so not really a downgrade either. I have a few ideas about the optimal mode of operation of some future clipboard solution (and management of window focus is definitely a part of it), but probably better not to hijack this thread.
And one more note: I feel like that in an optimal case the user intent (in form of user initiated action) should be probably at the center of both solutions (window focus management / clipboard access). A window should be able to get focus only if it's creation was clearly initiated by the user. Same goes for the clipboard - by default, the application should gain clipboard (read) access only if it's in focus and some global (system defined) keyboard shortcut was pressed. The moment it loses focus the clipboard access should be revoked.
Just mentioned the clipboard problem as focus stealing prevention is an important requirement for that to be well-working, but even though I'm also looking forward to that, as you mentioned it would be best not to hijack the topic here with that. Do note though that some users are already upset with Wayland limitations so the default might never change, but part of what makes KDE so great is the possibility of customization, so the current overly permissive approach could be kept as the default option, while business / privacy oriented setups should be able to opt into the requirement you described. User initiation alone is not a good enough requirement though, but it would be a good start. The earlier described problem of a call popping up while typing just really shouldn't happen, but the focus on launch problem satisfies the user initiation requirement while still being an annoyance. The worst case I tend to see is with Krusader as I tend to work over the network with large files using it. Not sure right now which part likes to pop up, maybe the "Synchronize Folders..." part which tends to open windows (especially in case of errors), but occasionally I run into the oddity of starting an operation (satisfying user initiation), then possibly hours later Krusader pops up either just indicating it's finished, or wanting attention for some other reason.
> Do note though that some users are already upset with Wayland limitations so > the default might never change, but part of what makes KDE so great is the > possibility of customization, so the current overly permissive approach > could be kept as the default option, while business / privacy oriented > setups should be able to opt into the requirement you described. I feel like there is a middle ground here. You could have "special" apps with elevated permissions and specific targeting (so they can't be abused system-wide by any running app.). As a more general case, maybe something like an Android permission model could be implemented. I could (for example) imagine a pupose build "keybord paste" application (less general xdotool/ydotool), that could be used by password managers to type-out the password. They would also need some authentication token for that (so other apps can't abuse them and generate user input). > > User initiation alone is not a good enough requirement though, but it would > be a good start. The earlier described problem of a call popping up while > typing just really shouldn't happen, but the focus on launch problem > satisfies the user initiation requirement while still being an annoyance. Maybe we have a terminology problem here. What I meant by "user initiated action" was some form of user interaction that leads to creation of the new window. (A backgroud running) Krusader popups in my opinion definitely don't satisfy that requirement. Focusing a popup generated by app already in focus is fine. Otherwise I would prefer just some form of "Application requires attention" notification like the highlighted task bar icon we used to have in X11. No automatic focus switch and definitely no workspace / activity switching. A nice rule of thumb (not requiring any specific rules) could probably be following the PID tree. Does the parent process (or more generally any ancestor) currently have focus? If yes we can switch it to the new window, otherwise only the "new window notification" is allowed (and even that should be probably skipped if the new window is on the current workspace & comes partially into view). That should cover even the KRunner / App Launcher case.
> A nice rule of thumb (not requiring any specific rules) could probably be > following the PID tree. Does the parent process (or more generally any > ancestor) have focus? Just as I sent the above, I realized that the (more general) ancestor rule probably isn't a good idea. It would certainly require some additional cutoff rules: - Pure direct parent rule would probably work most of the time, but there might be a lot of applications that spawn the new GUI process indirectly (with one or more PIDs in between). - General PID ancestor rule would then fail for example in case of the KRunner: Any application spawned by Krunner could steal the focus in the moments when KRunner is in focus itself. Maybe the ancestor cutoff rule could be the first PID above (including self) that has/had a GUI (window). The idea needs some work for sure. Any counter-examples would help developing it further.
My personal user perspective: I initially switched to Linux, because KDE had window rules, while Windows10 just removed per app focus stealing prevention. I am an extremely impatient person and I always do something different if some app takes a while. Often I find myself in situations like these: A: I press the update button in pamac, it downloads packages. I start a browser and type something into the search bar. Pamac steals focus because it finished downloading and spawns an update confirmation dialogue and by pressing enter it cancels the update. B: I launch a game through steam. While it loads, I want to start a freetube video at a specific timestamp on a secondary monitor. I grab the video timebar to scrub through it for the right moment. Before I can release it, the game grabs focus and my mouse cursor with it. Now the video timeline is all the way to the left. I have to tab out, and start over. A could be solved through https://bugs.kde.org/show_bug.cgi?id=364689 B was already solved by creating window rules for all games and just forcing them to never steal focus, but now on Wayland it doesn't work anymore
i ran into this problem because i want it to be "none" as i dont focus stealing id rather just the window pop up. if i switch to x11 and set it. mild testing here ill update if it doesn't work, it seems the settings work. replication for the bug was: fill all the screens use an application called aesprite to open dolphin the window would flash in the panel. click it and its focused. mildly annoying signed out switch to x11 logged back in filled the screen with the same applications no matter how many times i try. window pops up focused. note: i did change the window size of dolphin and the new dolphin aesprite open reflected that size. *dont know if this is important
Any news? I also want to set the focus stealing prevention to "None" (globally is fine), and it fails (at least tried with Okular). Here is my use case: when compiling latex documents in emacs, typing "C-c C-a" would compile the document to a pdf, and display the PDF with okular (often okular will just refresh the pdf). The problem is that every time I compile, I need to manually click on Okular (that flashes orange in the menu bar) to see the new pdf. Given that I compile maybe 30s maybe, especially when doing tikz pictures, manually clicking on okular can become really a pain. To reproduce: find a pdf and type: $ okular --unique mypdf.pdf & # Go back to the terminal and type: $ okular --unique mypdf.pdf & # normally this would put the focus on okular. Not in wayland.