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.
I like to have a new Emacs frame pop up for Org capture, but when the frame closes, focus is then given to Emacs instead of being restored to whatever I was using before I used the global hotkey to summon the new frame for the Org-capture buffer.
I have the same problem for opening any text file in a text editor from a separate terminal emulator. If I have any other editor windows open, if I save and close that file, focus is not restored to my terminal application.
It should be noted that this isn't true focus stealing, which is when a new window (that you didn't ask for) pops up and suddenly grabs focus from what you're doing. This is just macOS' app-based rather than window-based GUI task switching behavior sucking like it has always sucked.
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.
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.
Agree to both points. The UI part of macOS is trash, and there are a few times I'd like to have kept a window on top but couldn't despite the random updaters and reminders doing it without asking.
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?
On macOS you can have an app that is running without any windows open and you use the menu bar to invoke different commands in that app. This is why cmd+tab allows you to switch to an app that doesn't have any window open, essentially cmd+tab is an app switcher and not a window switcher. If you want a window switcher you can use AltTab an open source window switcher for macOS.
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 the desktop specifically and not in any other case, eg tabbing or closing other windows.
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 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.
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).
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.
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!"
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.
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.
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.
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.
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!
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.
> 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!
Great. It's really annoying to be typing my password to unlock my password manager, immediately after logging in, only for discord to pop up and steal focus, because it takes long to load. Switch back, try entering the password again and now steam launches and steals the focus again.
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.
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.
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.
It's infuriating that browser vendors still haven't dealt with extensions stealing focus. Every time I turn my seldomly-used laptop, one of extensions decides it's extremely important to show me a change log or something. I don't even remember what extensions I have as long as these function as expected.
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.
Where has macOS focus stealing let you down other than Microsoft applications?
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.
I like to have a new Emacs frame pop up for Org capture, but when the frame closes, focus is then given to Emacs instead of being restored to whatever I was using before I used the global hotkey to summon the new frame for the Org-capture buffer.
I have the same problem for opening any text file in a text editor from a separate terminal emulator. If I have any other editor windows open, if I save and close that file, focus is not restored to my terminal application.
It should be noted that this isn't true focus stealing, which is when a new window (that you didn't ask for) pops up and suddenly grabs focus from what you're doing. This is just macOS' app-based rather than window-based GUI task switching behavior sucking like it has always sucked.
Hilariously LibreOffice steals this "functionality", at least in KDE.
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.
I get various app update dialogs opening up and stealing focus. Fusion360 is pretty bad when you open it - it takes forever too.
Focus stealing happens quite a lot on macOS.
The VPN client I use for work will pop up and steal focus every few minutes if it's running but not logged in.
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.
Agree to both points. The UI part of macOS is trash, and there are a few times I'd like to have kept a window on top but couldn't despite the random updaters and reminders doing it without asking.
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.
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.
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.
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?
On macOS you can have an app that is running without any windows open and you use the menu bar to invoke different commands in that app. This is why cmd+tab allows you to switch to an app that doesn't have any window open, essentially cmd+tab is an app switcher and not a window switcher. If you want a window switcher you can use AltTab an open source window switcher for macOS.
Why is there no finder specific setting that if it receives focus and has no window open it automatically creates the default one?
The current behavior is such a terrible user experience.
I don't know how a company as big as apple can leave everyday things in such a terrible state.
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.
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 the desktop specifically and not in any other case, eg tabbing or closing other windows.
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.
Thankfully it's quite easy to go for several weeks without rebooting, but this is so annoying.
Oh my. Yes.
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".
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.
Correct, so the launch token should get invalidated when the user breaks the figurative focus queue by changing focus
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 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.
I think it's unreasonable for any app to be so slow to launch that this matters.
That doesn't change the fact that very many apps are in fact that slow that it does matter.
I'm on an HDD and Signal Desktop is 400+ MB, so
The network is always down, the disk is always slow, and the OS never schedules your threads. Keep those in mind and your code might be good
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.
Bring back splash screens! If your application takes ages to open, throw up a nice little title card.
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.
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'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!"
Determining when an app is fully ready to actually use sounds like it might have Halting Problem issues?
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.
[1] https://www.freedesktop.org/software/systemd/man/254/sd_noti...
[2] https://kubernetes.io/docs/concepts/configuration/liveness-r...
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.
> Whats the use-case of focusing windows? > Ticket closed This is what gnome will do.
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.
Yeah this is a bug: https://gitlab.gnome.org/GNOME/mutter/-/issues/4195
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 :)
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.
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.
I like KDE a lot, but this part of it needs work.
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.
I suspect a lot of that comes from the "how to detect whether window x is window x" settings
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.
My personal experience using KDE on Wayland, certain electron-based applications have been huge pains about stealing focus when they really shouldn't.
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:
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!
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.
It's the same everywhere, and it's unbelievable that it's been allowed for so long.
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.
> 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!
Great. It's really annoying to be typing my password to unlock my password manager, immediately after logging in, only for discord to pop up and steal focus, because it takes long to load. Switch back, try entering the password again and now steam launches and steals the focus again.
I'm glad this can be turned off. Choice is why I use KDE.
I use many older pieces of software which will probably never implement this. And I never have issues with focus stealing with the stuff I use.
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.
"DnD" == "Do Not Disturb"
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?
Nice. Open source lends itself well to folks refining tiny but crucial details until they are really nice - or at least really configurable.
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.
Oh you are typing a password? Let's change the focus to some random insecure window.
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.
Hah. Just yesterday Bambu studio did this shenanigan when the application crashed. 10 focus changes within a 1 second, repeat indefinitely.
It was infuriating. Had to reboot and it does it on every filament sync now.
It's infuriating that browser vendors still haven't dealt with extensions stealing focus. Every time I turn my seldomly-used laptop, one of extensions decides it's extremely important to show me a change log or something. I don't even remember what extensions I have as long as these function as expected.