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 · 3h 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 · 3h ago
Where has macOS focus stealing let you down other than Microsoft applications?
lynndotpy · 45m ago
This happens to me regularly on computers running MacOS, including with system prompts that appear too quick while I'm typing for me to tell you what I even hit enter/space on.
troyvit · 2h ago
Hilariously LibreOffice steals this "functionality", at least in KDE.
nottorp · 2h ago
I think about everything that's not made by Apple focus steals. And Apple allows them.
I suppose that's why they developer liquid glass, if they make the screen unreadable it won't matter that the wrong application is focused.
williamdclt · 2h ago
My "favourite" (/s) feature is windows that _stick_ on top of others. Like, some updater for some app that just stays on top of other windows even without having the focus.
Oh, and all these times where a running program doesn't want to be focused. I run my shortcut to focus it, nothing. I type its name in spotlight, nothing. I click its icon in the dock, magic, it gets into focus!
Or when the dock doesn't hide away as it should but just stays there for unknown reasons.
o11c · 29m ago
For the first thing:
Right click the titlebar (or left-click the icon at the left corner thereof) -> M_ore Actions -> uncheck "Keep A_bove Others".
Personally I activate it quite frequently, e.g. to keep a small text editor or terminal open in front of a maximized browser window for reference.
ben0x539 · 2h ago
I just wrote a "program" (ok, tiny utility) that behaves like you describe, but don't worry, it's for my personal use so you you won't have to deal with it :)
(i run it when I have an image in the clipboard and it shows an always-on-top window with that image. i can drag it around but it doesn't take focus. it's so on my single monitor setup (aka laptop on the couch) I can take a snapshot of something and then easily reference it in a maximized/semi-fullscreen application). I honestly mostly wrote it to see how fiddly winapi stuff from rust is but I actually end up using it a bunch)
I see where Wayland is coming from but I've come around to preferring the chaos of every app getting to do whatever it wants over hoping that various compositors are willing to support some obscure special case some app or other might want. Like, it sucks if apps are misbehaving but it sucks more if you can't reasonably fix an app to behave like you want it at all.
bayindirh · 2h ago
KDE has special settings for focus-stealing and focus-protection. You can apply these settings per window, per window-class, per application.
So, anything breaking these very mature mechanisms is a red flag, and is taken seriously.
dsego · 1h ago
What I want on macos is that Finder can't have focus if there are zero finder windows on top and the desktop is not fully uncovered, maybe not even then. What already happened once for me is that I accidentally triggered undo thinking I had Firefox focused, because that was the visible window, and I failed to look at the menu bar, so instead I managed to undo a copy or move action in Finder, I'm not even sure what it was, because all you get is a plink sound and Finder doesn't help you figure out what you just did. It's a recipe for disaster, I imagine I could unknowingly screw things up big time.
butokai · 1h ago
I just moved to macOS for the first time, and my only way to adapt to its multi-tasking has been keeping exactly one window per open application, never zero or more than one. The fact that Finder can't be treated like that is a real pain. I will focus on it essentially randomly, and it will disrupt my intended interaction.
I don't get the reasoning behind the zero-window cmd-tab interaction, but if it is there I guess that there's a reason behind it?
duskwuff · 57m ago
Consider that, with your proposal:
1) If you had a single Finder window open, then closed it, focus would get stolen by whatever other application happened to have a window open.
2) There would be no way to use the keyboard to interact with an item on the desktop without first closing or hiding every running application.
dsego · 6m ago
Truth be told, the desktop is already a kind of weird folder that is obstructed by all other windows, so I wouldn't really care about those types of inconsistencies. So for the first case, I wouldn't mind if closing the last finder window would jump to the next app in the tabbing order as if I quit it. The second case is a bit more tricky, but I think it's should be a matter of focusing only if I click on it specifically and not in any other case, eg tabbing or closing other windows.
prmph · 3h 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.
wyan · 32m ago
Thankfully it's quite easy to go for several weeks without rebooting, but this is so annoying.
pjerem · 2h ago
Oh my. Yes.
rollcat · 4h 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 · 3h 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.
mrob · 19m ago
I think it's unreasonable for any app to be so slow to launch that this matters. Modern SSDs have 7000MB/s or more read speeds. Assuming a ridiculously bloated app of 100MB, that's enough to load the whole thing into RAM in less than a frame at the most common monitor refresh rate. The only explanation for slow load times on modern hardware is bad software.
eviks · 2h ago
Correct, so the launch token should get invalidated when the user breaks the figurative focus queue by changing focus
nottorp · 2h ago
Powe user ish thing i guess, but i do start multiple applications without waiting for any launch to finish, and I'd love for the one I actually want to stay focused.
ben0x539 · 2h ago
I bet there's concerns with users who don't have a robust mental model of what applications/windows are currently alive or starting up or whatever just losing track of a window completely if it doesn't grab focus, and getting annoyed at programs seemingly failing to start up at all (because they only create a window hidden behind a newly focused window).
One-size-fits-all woes I guess.
carlosjobim · 1h ago
There's a bounce animation with the application icon in the dock, and then there's a dot next to the icon to show that the application is open. That should be enough for all users.
phkahler · 3h 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 · 3h 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!"
zuminator · 2h ago
Determining when an app is fully ready to actually use sounds like it might have Halting Problem issues?
eliaspro · 1h ago
The very fundamental problem is just, that the fact that the process/application/service has a PID/displays a window does not equal to the fact, that the service/application is ready to serve requests/the user.
This is why there are protocols like sd_notify [1] or readinessProbe [2] to determine the actual state of the launched service/process/application.
Gnome should follow suit. I still have problems with context menus stealing focus and locking it to the window where they are opened.
When I right click in nautilus I have to close that menu before I can click anything not-nautilus.
It happens in every gnome application with 2 out of 3 mouse devices and it drives me nuts.
I still can't drag and drop if I alt-tab to a different window. All of these were introduced after 3.0, but have not been considered severe enough to fix.
margalabargala · 4h 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 · 3h 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 · 3h 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.
o11c · 20m ago
Don't confuse "window rules" with "application rules". When configuring rules, you normally want the latter unless you know you want the former.
Also don't forget that rules can interact with other rules. For example, window size interacts with all of: "fullscreen", "maximized", and the "geometry" options (commonly set to more than 1 pixel for terminals).
That said, I am really not a fan of the recent UI-pessimization of the settings screen to require you to type out the setting you want rather than have tabs listing all the various options in a discoverable manner.
dmonitor · 2h ago
I suspect a lot of that comes from the "how to detect whether window x is window x" settings
jm4 · 3h 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 · 2h 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 · 3h 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 · 3h 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
DonHopkins · 2h ago
Not only focus stealing, but focus hostage taking, when one application steals the focus and won't give it back!
Sun's notorious XBugTool stole both my input focus AND mouse motion, and held me hostage when I tried to file a bug against its XView buddy cmdtool. Here is the bug report I filed against the X11/NeWS server as a desperate cry for help while I was trapped in xbugtool's grabby clutches:
Date: Mon, 20 May 91 22:45:46 PDT
Bug Id: 1059974
Category: x11news
Subcategory: server
Bug/Rfe: bug
Synopsis: I have no mouse motion and my input focus is stuck in xbugtool!!!
Keywords: I have no mouth and I must scream [Harlan Ellison]
Severity: 1
Priority: 1
Description:
This is my worst nightmare! None of my TNT or XView applications are
getting any mouse motion events, just clicks. And my input focus is
stuck in xbugtool, of all places!!! When I click in cmdtool, it gets
sucked back into xbugtool when I release the button! And I'm not using
click-to-type! I can make selections from menus (tnt, olwm, and xview) if
I click them up instead of dragging, but nobody's receiving any mouse
motion!
I just started up a fresh server, ran two jets and a cmdtool, fired up
a bugtool from one of the jets (so input focus must have been working
then), and after xbugtool had throbbed and grunted around for a while
and finally put up its big dumb busy window, I first noticed something
was wrong when I could not drag windows around!
Lucky thing my input focus ended up stuck in xbugtool!
The scrollbar does not warp my cursor either... I can switch the input focus
to any of xbugtool's windows, but I can't ... -- oomph errrgh aaaaahhh!
There, yes!
Aaaaah! What a relief! It stopped! I can move my mouse again!!
Hurray!!! It started working when I opened a "jet" window, found I
could type into it, so I moved the mouse around, the cursor
disappeared, I typed, there were a couple of beeps, I still couldn't
find the cursor, so I hit the "Open" key, the jet closed to an icon,
and I could type to xbugtool again! And lo and behold now I can type
into the cmdtool, too! Just by moving my cursor into it! What a
technological wonder! Now I can start filing bug reports against
cmdtool, which was the only reason I had the damn thing on my screen in
the first place!!! I am amazed at the way the window system seems to
read my mind and predict my every move, seeming to carry out elaborate
practical jokes to prevent me from filing bugs against it. I had no
idea the Open Windows desktop had such sophisticated and well
integrated interclient communication!
pseudocomposer · 4h 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 · 4h 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 · 3h ago
It's the same everywhere, and it's unbelievable that it's been allowed for so long.
eviks · 2h ago
> The file manager then launches your PDF viewer and hands it the token. The PDF viewer, upon starting, shows this token to the compositor and asks to be activated. The compositor checks if the token is legit and, if so, gives the PDF viewer focus.
>If the token is missing, old, or otherwise invalid, the compositor says no.
Doesn't seem to go far enough. If this is a long operation and you switch to another app to read a page in a browser, will the opened PDF steal focus from your reading or allow you to switch to PDF at your own leisure?
> The viewer window will not get focus, and instead, its icon in the taskbar will start flashing to grab your attention.
This is just a common awful alternative. There is nothing important about this activity to flash, charging the style once would be just fine. But at least it's not jumping up like the UI geniuses at Apple have done.
But otherwise, great initiative, focus stealing is a serious UI crime!
ghusto · 3h 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 · 3h ago
"DnD" == "Do Not Disturb"
nottorp · 2h ago
Can't you just not allow applications to request focus from themselves, and allow focus changes only from the window manager based on user actions?
rpgbr · 1h ago
macOS Sequoia (or Sonoma) changed behavior when you right click a link on Safari having its window in background. The context menu shows up and previous foreground app loses focus, but Safari doesn't get it/stays in background, so you basically have no window on focus.
SubiculumCode · 1h ago
Oh you are typing a password? Let's change the focus to some random insecure window.
whalesalad · 4h 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 suppose that's why they developer liquid glass, if they make the screen unreadable it won't matter that the wrong application is focused.
Oh, and all these times where a running program doesn't want to be focused. I run my shortcut to focus it, nothing. I type its name in spotlight, nothing. I click its icon in the dock, magic, it gets into focus!
Or when the dock doesn't hide away as it should but just stays there for unknown reasons.
Right click the titlebar (or left-click the icon at the left corner thereof) -> M_ore Actions -> uncheck "Keep A_bove Others".
Personally I activate it quite frequently, e.g. to keep a small text editor or terminal open in front of a maximized browser window for reference.
(i run it when I have an image in the clipboard and it shows an always-on-top window with that image. i can drag it around but it doesn't take focus. it's so on my single monitor setup (aka laptop on the couch) I can take a snapshot of something and then easily reference it in a maximized/semi-fullscreen application). I honestly mostly wrote it to see how fiddly winapi stuff from rust is but I actually end up using it a bunch)
I see where Wayland is coming from but I've come around to preferring the chaos of every app getting to do whatever it wants over hoping that various compositors are willing to support some obscure special case some app or other might want. Like, it sucks if apps are misbehaving but it sucks more if you can't reasonably fix an app to behave like you want it at all.
So, anything breaking these very mature mechanisms is a red flag, and is taken seriously.
I don't get the reasoning behind the zero-window cmd-tab interaction, but if it is there I guess that there's a reason behind it?
1) If you had a single Finder window open, then closed it, focus would get stolen by whatever other application happened to have a window open.
2) There would be no way to use the keyboard to interact with an item on the desktop without first closing or hiding every running application.
- 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.
One-size-fits-all woes I guess.
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!"
This is why there are protocols like sd_notify [1] or readinessProbe [2] to determine the actual state of the launched service/process/application.
[1] https://www.freedesktop.org/software/systemd/man/254/sd_noti...
[2] https://kubernetes.io/docs/concepts/configuration/liveness-r...
When I right click in nautilus I have to close that menu before I can click anything not-nautilus.
It happens in every gnome application with 2 out of 3 mouse devices and it drives me nuts.
I still can't drag and drop if I alt-tab to a different window. All of these were introduced after 3.0, but have not been considered severe enough to fix.
I like KDE a lot, but this part of it needs work.
Also don't forget that rules can interact with other rules. For example, window size interacts with all of: "fullscreen", "maximized", and the "geometry" options (commonly set to more than 1 pixel for terminals).
That said, I am really not a fan of the recent UI-pessimization of the settings screen to require you to type out the setting you want rather than have tabs listing all the various options in a discoverable manner.
Sun's notorious XBugTool stole both my input focus AND mouse motion, and held me hostage when I tried to file a bug against its XView buddy cmdtool. Here is the bug report I filed against the X11/NeWS server as a desperate cry for help while I was trapped in xbugtool's grabby clutches:
https://www.donhopkins.com/home/catalog/unix-haters/x-window...
This is my worst nightmare! None of my TNT or XView applications are getting any mouse motion events, just clicks. And my input focus is stuck in xbugtool, of all places!!! When I click in cmdtool, it gets sucked back into xbugtool when I release the button! And I'm not using click-to-type! I can make selections from menus (tnt, olwm, and xview) if I click them up instead of dragging, but nobody's receiving any mouse motion!I just started up a fresh server, ran two jets and a cmdtool, fired up a bugtool from one of the jets (so input focus must have been working then), and after xbugtool had throbbed and grunted around for a while and finally put up its big dumb busy window, I first noticed something was wrong when I could not drag windows around!
Lucky thing my input focus ended up stuck in xbugtool!
The scrollbar does not warp my cursor either... I can switch the input focus to any of xbugtool's windows, but I can't ... -- oomph errrgh aaaaahhh! There, yes!
Aaaaah! What a relief! It stopped! I can move my mouse again!! Hurray!!! It started working when I opened a "jet" window, found I could type into it, so I moved the mouse around, the cursor disappeared, I typed, there were a couple of beeps, I still couldn't find the cursor, so I hit the "Open" key, the jet closed to an icon, and I could type to xbugtool again! And lo and behold now I can type into the cmdtool, too! Just by moving my cursor into it! What a technological wonder! Now I can start filing bug reports against cmdtool, which was the only reason I had the damn thing on my screen in the first place!!! I am amazed at the way the window system seems to read my mind and predict my every move, seeming to carry out elaborate practical jokes to prevent me from filing bugs against it. I had no idea the Open Windows desktop had such sophisticated and well integrated interclient communication!
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.
>If the token is missing, old, or otherwise invalid, the compositor says no.
Doesn't seem to go far enough. If this is a long operation and you switch to another app to read a page in a browser, will the opened PDF steal focus from your reading or allow you to switch to PDF at your own leisure?
> The viewer window will not get focus, and instead, its icon in the taskbar will start flashing to grab your attention.
This is just a common awful alternative. There is nothing important about this activity to flash, charging the style once would be just fine. But at least it's not jumping up like the UI geniuses at Apple have done.
But otherwise, great initiative, focus stealing is a serious UI crime!
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.