This is, quite unironically, the type of development I wish Apple would pursue for macOS. It's 2025 and focus stealing is still a topic we can have a serious conversation about. Why? "I want to use my computer without random popups accidentally eating my keyboard commands and doing things without my consent" is not /that/ unreasonable of an ask.
seemaze · 30m ago
Oh man, I loathe when I close a Microsoft Excel window on macos and my whole desktop virtual space jumps to some other virtual space that happens to still have an Excel window open.
Only slightly less irksome is that the undo history spans all open documents commingled.
emchammer · 19m ago
Where has macOS focus stealing let you down other than Microsoft applications?
prmph · 15m ago
Yeah, starting MacOS, with apps set to restore windows, is an exercise in frustration for the first minute or two. I try to work on the app I want, only to be constantly interrupted by many windows that keep popping up and stealing the focus.
pjerem · 4m ago
Oh my. Yes.
rollcat · 1h ago
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".
dagw · 1h ago
I've just launched the application
Honestly even this is questionable. If a running app gets focus between me asking for the new app to launch and that app actually launching, I probably want the existing app that has focus to keep focus until I actively click on the window of the new app.
phkahler · 1h ago
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.
ghusto · 1h ago
> 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!"
jm4 · 50m ago
Is focus stealing a real problem? I am a longtime Linux user and I happen to use KDE on Wayland. I wasn’t even aware this was a thing. Which desktops and apps is this happening with?
weberer · 6m ago
I've only seen this with Steam. It would throw up several small "loading" windows, each stealing focus, before actually launching (and stealing focus again).
I haven't noticed it in a while though. Maybe they fixed it.
connicpu · 16m ago
My personal experience using KDE on Wayland, certain electron-based applications have been huge pains about stealing focus when they really shouldn't.
treve · 46m ago
Gnome user, but for me one of the last major issues with Wayland is lack of focus stealing, including KeepassXC appearing under my browser when I need it
margalabargala · 1h ago
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.
robhlt · 1h ago
This is already supported! KDE has a really powerful "window rules" feature that lets you configure all kinds of properties on specific windows/apps, and focus stealing prevention is one of them. Just right click the app's title bar and under "more actions" you'll see "Configure Special Window/Application Settings...". The rule configuration window isn't the easiest to use, but "Add Property" is how you can set properties on windows that match the new rule.
prmph · 19m ago
This windows rules feature seems to be bug ridden. Yesterday I struggled with it all day. Rules were not being followed properly, were erased mysteriously, etc.
I like KDE a lot, but this part of it needs work.
dmonitor · 4m ago
I suspect a lot of that comes from the "how to detect whether window x is window x" settings
pseudocomposer · 1h ago
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?
sho_hn · 1h ago
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.
ghusto · 1h ago
It's the same everywhere, and it's unbelievable that it's been allowed for so long.
ghusto · 1h ago
I'm so happy someone's doing something about this.
I've had to resort to using my iPad with a keyboard for when I can't stand distractions. DnD on iPad/iPhone actually does what it says on the tin, because applications can't bypass it with direct access to the screen like they can on a desktop.
hollerith · 1h ago
"DnD" == "Do Not Disturb"
whalesalad · 1h ago
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.
Only slightly less irksome is that the undo history spans all open documents commingled.
- 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".
Honestly even this is questionable. If a running app gets focus between me asking for the new app to launch and that app actually launching, I probably want the existing app that has focus to keep focus until I actively click on the window of the new app.
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.
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!"
I like KDE a lot, but this part of it needs work.
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.
I've had to resort to using my iPad with a keyboard for when I can't stand distractions. DnD on iPad/iPhone actually does what it says on the tin, because applications can't bypass it with direct access to the screen like they can on a desktop.
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.