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.
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.
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.
> 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.
Then in Apple's infinite wisdom, doesn't let you manually set a window to be always on top - one of my most missed features from Gnome, KDE, and even Windows has it with PowerToys.
I love my macbook's hardware, but macOS has to be one of the most frustrating operating systems I've ever used.
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.
I actually really like the AmigaOS way. Where all windows have this behaviour. In fact, bringing something to the foreground is an explicit action. Sounds weird, but it allows you to, for example, drag something from a background window to the foreground one, or have a background window in focus.
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.
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?
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.
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.)
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.
I'd amend rollcat's statement to say something like: "I've just launched this application and not pressed another key or clicked a mouse button since then."
Once you do that, too fucking late application. Should've been faster, now you don't get focus until I actively do something.
That being said, I've only ever really noticed focus stealing issues happening on Windows or OS X, never Linux.
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).
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.
Applications should take about 1s to launch (median for Apple's native apps), including under moderate load, so this problem should never be perceptible. But the fallback behavior you describe is perfectly reasonable.
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.
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.
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!"
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.
Yep, been there. It's baffling just how strange Gnome devs' priorities are, not to mention how they interact with the community. Rest of the DEs seem to be more "Okay, community said this, let's try this with x or y." Gnome is more "We know best, no we're not listening to you" from all the interactions I've had with gnome devs.
"Can you tell me a use case for this?" for a feature for example present in every other DE. I forgot what the exact context was or I'd pull up the ticket. Something to do with the sorting of files from the header of the sort display or some such.
Focus stealing is when a window unexpectedly acquires focus. You’re describing something different, a window not relinquishing focus because of a chosen and consistent (not universally appreciated, but justifiable) behaviour for modals.
I have had so many focus issues on gnome that what I meant is that they should do a new take on the whole thing. The problem has gotten worse, not better, over the years.
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.
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.
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.
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?
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.
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
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!
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.
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?
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.
This is a perfect example of how FLOSS is nowadays a truly different type of experience from commercial software: thanks to A/B-tests, software has become so good at manipulating our behavior that it's now often more profitable to optimize software not to be the best at what it's supposed to do but at stealing your time and attention. Ads and (extremely clickbaity) 'news' plastered all over W11 are a prime example, and the exact opposite of what the KDE team are doing here.
Readit News
Only slightly less irksome is that the undo history spans all open documents commingled.
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.
Then in Apple's infinite wisdom, doesn't let you manually set a window to be always on top - one of my most missed features from Gnome, KDE, and even Windows has it with PowerToys.
I love my macbook's hardware, but macOS has to be one of the most frustrating operating systems I've ever used.
(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.
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.
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.
Once you do that, too fucking late application. Should've been faster, now you don't get focus until I actively do something.
That being said, I've only ever really noticed focus stealing issues happening on Windows or OS X, never Linux.
One-size-fits-all woes I guess.
Applications should take about 1s to launch (median for Apple's native apps), including under moderate load, so this problem should never be perceptible. But the fallback behavior you describe is perfectly reasonable.
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!"
Deleted Comment
Deleted Comment
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.
"Can you tell me a use case for this?" for a feature for example present in every other DE. I forgot what the exact context was or I'd pull up the ticket. Something to do with the sorting of files from the header of the sort display or some such.
I have had so many focus issues on gnome that what I meant is that they should do a new take on the whole thing. The problem has gotten worse, not better, over the years.
This happens on any GTK apps on KDE as well, so it seems to be a toolkit bug instead of compositor bug.
Apparently this happens only when you have a mouse that have those additional buttons that are exposed as a "keyboard" to the system :)
I like KDE a lot, but this part of it needs work.
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!
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.
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.