Skip to content(if available)orjump to list(if available)

KDE Plasma prepares crackdown on focus-stealing window behavior under Wayland

rollcat

IMHO every desktop environment (yes, looking at you, macOS) should aggressively block focus stealing. The only conditions under which focus should change:

- I've just launched the application

- I've clicked on a window

- I've clicked the window's icon in the dock

- I've cmd-tabbed (or equivalent) to this window

- The currently focused window has produced a modal dialog, that prevents all input events from going into the original window. (Whether and when modal dialogs are OK is debatable.)

Matthew 5:37, "anything more comes from evil".

ghusto

> I've just launched the application

I'd even have a special sub-criterion under this: The application may only take focus once it is _ready to actually use_.

Slack is a prime example of how apps steal focus multiple times during startup: I start the app, cmd+tab to something else whilst I'm waiting, and it steals focus again at least 3 times before it's actually loaded and usable.

You can have focus once I can actually do something, not to show me "HEY LOOK I'VE LOADED YET ANOTHER BLOATED COMPONENT!"

phkahler

I would add "I've just opened this file" which is close to "just launched the app". That requires a bit of plumbing though since it's user interaction with another app which then tells the system to open the file (and hence launch the app for it). It sounds like that's what KDE is doing here, passing the user permission (granted by double click) on to whatever opens the file.

In general I agree that most system access should only be allowed if its an actual user intent through the GUI or whatever. Obviously certain things might be granted exceptions, but the norm should be more restrictive.

margalabargala

My ideal state of this feature is probably one that mostly behaves as "normal", but lets me mark individual badly behaving, user-hostile applications like Zoom as unable to steal focus when they abuse it.

pseudocomposer

Interesting reading, and it’s nice to see how they’ve implemented it and tweaked the KDE app suite to manage focus better as a result. Does anyone know whether there are (or have been) analogous issues on macOS/Windows? And what about GNOME or maybe XFCE?

ghusto

It's the same everywhere, and it's unbelievable that it's been allowed for so long.

sho_hn

It's all more or less the same between Plasma/Gnome/XFCE. On X11 all window managers had to employ roughly similar heuristics-based tactics. That does however mean there might be behavior differences based on the specific WM's implementation.

The token-based activation protocol for Wayland is a shared development that has been adopted across different toolkits, and I imagine will probably also result in more consistent default behavior across environments, although of course in theory a given compositor could decide or be configured to whatever flavor of stealing prevention is wanted.

I can't comment much on macOS/Windows technically, except that my standard user experience on Windows installs is that at least once per week, some OEM background thing decides to update something that for some reason requires running a cmd.exe terminal window that reliably steals focus from whatever I'm doing. This kind of thing hasn't really been an issue on Linux DEs for decades.

whalesalad

Oddly enough I find this to be annoying. 99.99% of the time when I want an app to take focus (ie, clicking a hyperlink from within a shell window), it won't and simply illuminates that app in the task bar (orange). Classic example is when you push a fresh branch to Github and they conveniently provide the "click here to make a PR" in the push response.

I just set my window stealing behavior setting to "None" to see if that improves things.

I have never had an app (on Linux/KDE) steal my attention inappropriately. I only experience the opposite - frustration that something I expect to become the new focus, front-and-center window, is not.