Hacker News Reader

Comment by nottorp | Hacker News Reader

I don't understand who historically has thought it's a good idea to allow applications to steal focus in the first place. It should be the window manager's decision, and the window manager should only switch focus if the user decides that.

View on HN

Well, sometimes the user expects the focus to shift, like the example mentioned when you click a link in one application and your browser in the background should come into focus when it opens a new tab. Some applications just decide to steal focus when the user does not expect it, and that is the problem.

I am not sure, as a convert to the church of "focus follows mouse" I sort of want well... my focus to follow the mouse and the mouse to follow me.

Now there may be a legitimate case to steal focus, but I am unable to think of one at the moments and your click link example fails to convince me.

I also sort of hate modal dialogs/windows. I think modals are in general an indicator of lazy/bad design. That being said, there are legitimate cases for modals. but "stop the world and handle me" should be a last resort not the first.

The legitimate use-cases for stealing focus are situations where an immediate response is required and timing is limited. For example: after you queue up for a ranked League of Legends game, there's a timed confirmation popup that appears when 10 players are found and which all players are required to accept before the game moves on to the draft.

In purely software spaces there's usually nothing that urgent happening. If something is really urgent it's usually going to be because it carries significant real-world consequences. Emergency alerts on smartphones are a good example of taking immediate priority over all other activities, especially if it's something like a warning of incoming missiles.

At the very least you need the ability to show the browser when you send a link to it. And if that overlaps the window you were clicking the link in, then it'll now be under the mouse. Are you happy with that indirect focus steal? If not, I don't think there's a way to align your preferences with the average user.

That's a situation where the focus doesn't need stolen at all, the focus could be delegated by the active window itself.

> delegated

Yes that's being included under "stolen" in this conversation, at least how I'm interpreting it. Done without explicit user action.

I'm of the cult of "focus follows mouse" as well but I think the same conversation exists regardless, just not for the specific case you already had your browser window positioned elsewhere from the window your mouse is currently over.

If you click a link in one application, surely it should pass focus to the browser, why should the browser be initiating that process?

Only the invoked app knows whether it needs the focus in the first place. Maybe the link you clicked is supposed to initiate some background processing that does not demand your focus at all.

Sure, so the previous app can give the option to take focus to the browser which can take it or not as it wishes.

Yes but there's no way for the OS to know if the focus request is legitimate, is there?

Can't even say "browsers are allowed to grab focus" because they'll grab it for a stupid window telling you to update the browser or what new features no one cares about they introduced.

I'd prefer to have to switch focus to the browser manually than have the stupid ubuntu update manager steal focus when i'm typing in the terminal...

The article is about a mechanism for the OS to validate focus requests. The application with the link requests a focus token, and passes it to the browser along with the open-link request, and the browser can then request focus.

It isn't perfect, because there's no way to know that the browser isn't using the token to request focus for something else, but maintaining and validating chain of custody for focus across applications is exactly the problem it looks like they are working on solving.

That was exactly the example given in the article, but somehow this isn't what I expected would happen if I click a link in say, my email client or chat program.

I imagined it more like: User clicks link in email program. Email program tells OS: "Here, open https://..." -- OS checks URL scheme registry and selects Firefox, OS brings Firefox to the front and throws the URL at it and says "Open this."

I guess perhaps my naïve way could falls down if the OS accepts URLs from apps that aren't in the foreground, so a random background process could activate any app it wants to steal focus.

Yep. With the solution discussed, as I understand it, the e-mail program just needs to be modified to request a focus token and send it along with the URL request to the browser or the OS browser dispatch service to keep the expected behavior.

This could be abstracted by libraries (e.g. a method in Qt to open a URL in the system browser automatically gets the token) so each application doesn't need to be updated separately, or possibly even OS services.

> Yes but there's no way for the OS to know if the focus request is legitimate, is there? Can't even say "browsers are allowed to grab focus" because [...]

To my understanding, the approach described in the article is that the currently active program requests a token and then passes that along to the program that it wants to take focus. Compositor can also check what triggered the request (mouse click? global keybind?) to decide if the request is legitimate.

That seems reasonable to me, opposed to requiring the user to switch over to a new window every time they `right click -> show in file browser` a file in their IDE, or after they press a hotkey to open a screenshot tool, or so on.

> Compositor can also check what triggered the request (mouse click? global keybind?) to decide if the request is legitimate.

That's what I'm dubious about. But I haven't look at the details ofc.

You think that's bad, back in the day when I was in an office where everyone used X terminals off of a common unix server, you could open a window on someone else's screen by just changing your DISPLAY environment variable. Fun pranks were fairly common.

KDE has KWin settings controlling this. I have no idea if this is some kind of a fixup after the fact or whether the window manager always controls this, but at least it does on a KDE X11 session.

Reply on news.ycombinator.com