Comment 26 for bug 35876

Revision history for this message
Bogdan Butnaru (bogdanb) wrote : Re: 'Downloading package information' and 'building dependency tree' progress dialogs steal focus

That isn't optimal either, actually it's the worst part:

I might be typing something in another application (an update takes a long time, which is why I minimized it in the first place). If a window needing input pops up unexpectedly and steals the focus, it's extremely likely that my last few key-strokes will get sent to the wrong window (i.e., the stealer). In cases where those key-strokes happen to mean something they can cause unwanted effects.

For instance, if I copy something and Nautilus asks me if I want to overwrite a directory (generally some destructive operation, it wouldn't ask otherwise), it would potentially cause a disaster if I was just happening to type a word that contains "y" (or any of the active shortcuts). If the update manager asks for input I can similarly cancel and loose an error log, or (un)install something I didn't want to. If I left something working for an hour to do something and then it asks me what to do with it and I accidentally tell it to just exit, I'd be very annoyed.

On several occasions I've had text windows and even terminals coming up while I was typing a password in another window. The effect of that is that (at least part of) my password is visibly typed on the screen, and someone can see it. If I also press enter before I notice the intruding window, the password can even be interpreted and get written in some log, etc.

Although rarer than typing, I've also seen (surprisingly often) cases where I typed a close command (alt+w or alt+f4) intending to close the window I'm working in and closed some window that happened to steal the focus. This can also cause lost data.

========

In general, focus should not pass to another window unless as a direct _and_ immediate effect of some explicit user action. In particular, the window manager is responsible to do that between applications. (It can't really do anything if a program incorrectly moves its focus.)

So, except for explicit alt+tab (and similar commands, for instance for switching workspaces), there should be _very_ few exceptions to the rule.

The only case I can think of is when the user does something like "run terminal" (which is a WM short-cut command) _and_ the terminal shows up very quickly (ie, under a second).

========

Note that putting the window on top without giving it focus is much less destructive, but it can be annoying. Also, if the new window is full-screen (or just large), it can be very annoying to the user (who suddenly can't see what he was doing).

Of course, if you just leave the window in the background, that's also annoying because the user won't notice it.

The best solution I've yet to see is how OS X makes icons "jump" on the task-bar when they need attention. That's very visible, but doesn't prevent the user from doing whatever he was doing, and it's also easy to ignore on purpose.

(Windows does this by blinking the application in the task-bar, but that's more annoying with auto-hide because it's harder to ignore.)