Dialogs of background applications pop up in the foreground

Run the attached script, put another window in front of the main window and wait two seconds. A dialog will be shown in front of all windows.

I don't know why the bugs I filed *earlier* are being marked as duplicates of this bug -- especially considering that what I reported is much more general than this. The problem is not restricted to dialogs. New windows -- in general -- should not steal the focus. Not only can this be a security issue when entering a password (notice how gksu prevents any window from opening), but it's also inconsistant with the "focus follows mouse" policy.

Which new window steals your focus? Metacity has a focus stealing prevention mechanism, for example new chat windows will not open in the front. So I thought that dialogs are the only ones that still cause an error.

Thank you for the bug and upstream pointer

I just now had a problem with update-manager stealing focus. This resulted in me answering some question in the update-manager terminal without having a clue to what the question was (because I was typing like crazy when the focus stealing occured).

This is related to https://launchpad.net/bugs/54300

Any news on this issue? It gets very annoying (and dangerous), particularly when typing passwords.

Load Pidgin, Evolution and other applications at the same time, each of which ask for a password. Try typing the corresponding password for each prompt as soon as you see it (without cursing during the process).

I also found this link: http://brainstorm.ubuntu.com/idea/400/ People who comment there think this behavior is not only annoying but a security risk also.

This is related to:

https://launchpad.net/bugs/227214

This focus stealing problem is really annoying in IM clients where focus gets stolen from your conversation window by the contacts window when one of your friends logs in or out... this can happen every few seconds.

Setting the "focus_new_windows" key to "strict" has fixed this problem for me (at least with update-manager--haven't tried much else as yet). Has anything been decided on what to do in future? This really is an extremely annoying "feature" and dangerous to boot. As others have noted, it's not that uncommon for windows to pop up and steal focus right as I'm trying to type a password. It has happened more than once to me.

The focus is really particular for me because it 's the opposate case disappoint me !

open gimp with a image, take nautilus open image with gimp and ... gimp stay background with the new image open, similar thing with gedit / geany and it's not usuable

Newly started applications often appear in front of Gnome-terminal when trying to type. When using focus-follows-mouse this is a disruptive, counter-intuitive behavior.

Not a paper cut because it is too complicated to fix, but this is a huge usability problem.

Does compiz exhibit the same behavior? It may be a consolation that we now turn compiz on by default, and more and more computers support it, so many new users may not be exposed to this behavior.

I am using compiz and I am having the same problem. I wasn't able to find an option to change that behavior in ccsm - hints welcome.

The problem also occurs when I launch an application that takes a view seconds to load, e.g. Firefox. When I am doing something else while waiting for Firefox to start, Firefox should not open in the foreground suddenly. When clicking or typing in another application while Firefox is still loading, Firefox should open in the background.

Of course Firefox is just an example, this should apply to all applications.

Dronus just suggested in the duplicate ( #51242 ) that there could be timed behavior to determine if a new window should have focus, but that's an intentional race condition. It would be better to see if the user has done anything since the window was requested... somehow...

The window manager should be able to know if the user is typing, at least.

On Fri, 07 May 2010 16:22:30 -0700, Thomas Folz-Donahue
<email address hidden> wrote:

> Dronus just suggested in the duplicate ( #51242 ) that there could be
> timed behavior to determine if a new window should have focus, but
> that's an intentional race condition. It would be better to see if the
> user has done anything since the window was requested... somehow...

I'd prefer a clearly distinguished notification about the window being
ready.

Other scenarios look unsafe to me.

--
Octavio.

In my opinion the behaviour should be this:

1. No window should ever take focus. It should only be possible to throw focus *to* another (possibly newly-opened) window.

2. When a new window appears, it should appear immediately behind the focused window (even if the focused window isn't frontmost). If no window is focused, the new window should open frontmost and focused.

3. When a launcher (or main menu item) is chosen, focus should be removed from all windows (and given to «nothing»).

This last rule means that if the user launches an application *and* doesn't throw focus to any existing window, the new window will appear frontmost and focused.

An amendment to the second rule might be that: if multiple new windows are opened while one window remains focused, the new windows should stack behind the focused window, such that the newest window is always added to the back of the stack.

On Sat, 08 May 2010 17:35:45 -0700, Greg K Nicholson <email address hidden>
wrote:
> 3. When a launcher (or main menu item) is chosen, focus should be
> removed from all windows (and given to «nothing»).

In this point you are assuming that the user will only launch
applications from an application related to the window manager.
Otherwise, there is a need for a function call for a third
party to remove the focus from any window.

I think it would be a security risk, as an application might
continuously take away the focus from any application.

Your point would only be useful as an optimization for a
particular environment, but what if you launch from the
terminal or from a third party launcher?

The other arguments of yours rely mostly on that.

The only universal solution I have come up with is a
non-stealing notification window (semi-transparent if
using a composite manager) saying "Your window
is ready, Sir."

The new window should have the URGENT hint set (as it is now)
but it must be made more apparent and attention-grabbing.

And an option to unset the URGENT hint from a Window without
necesarily having to bring it up front.

Just an idea.

--
Octavio.

Quoth Octavio Alvarez (2010-05-09 15:08):
> I think it would be a security risk, as an application might
> continuously take away the focus from any application.

No, I think the model Greg is proposing is essentially this: the
current focus is a privilege that at most one window may have. To
have it, it must be explicitly granted by something else, such as
the panel launcher.

Having this "non-stealing" and "focus stealing prevention" stuff
is doing it backwards.

I do wish these things would be thrashed out at freedesktop.org or
similar to get some standards around user interface expectations
and behaviour. It's about time we got some real user interface
standards instead of all this making stuff up and/or blindly
following the leader/competition.

a.

Octavio:
> In this point you are assuming that the user will only launch
> applications from an application related to the window manager.

Nope. gnome-panel is neither compiz nor metacity. It doesn't matter
which app does the launching.

> Otherwise, there is a need for a function call for a third
> party to remove the focus from any window.

No. No-one ever removes focus. The launching app relinquishes focus from itself.

> I think it would be a security risk, as an application might
> continuously take away the focus from any application.

It could only take focus away from itself.

> Your point would only be useful as an optimization for a
> particular environment, but what if you launch from the
> terminal or from a third party launcher?

The terminal or third-party launcher would (might) relinquish focus to
the new window.

> The other arguments of yours rely mostly on that.
>
> The only universal solution I have come up with is a
> non-stealing notification window (semi-transparent if
> using a composite manager) saying "Your window
> is ready, Sir."

gnome-shell implements exactly that (minus the assumption that the
user is male).

> The new window should have the URGENT hint set (as it is now)
> but it must be made more apparent and attention-grabbing.
>
> And an option to unset the URGENT hint from a Window without
> necesarily having to bring it up front.

With focus-follows-mouse on, pointing does this. Any additional
mechanism for removing the hint would be overkill, in my opinion.

> Just an idea.

avdd:
> No, I think the model Greg is proposing is essentially this: the
> current focus is a privilege that at most one window may have.

Yeah, fair enough.

> To
> have it, it must be explicitly granted by something else, such as
> the panel launcher.

Not quite. To lose focus, one must explicitly relinquish it—either to
«nothing» or to another window.

To gain focus, either another window throws focus to you; or your
window opens while nothing has focus. (This second case is the only
way a window can get focus without being explicitly given it by
another window.)

> Having this "non-stealing" and "focus stealing prevention" stuff
> is doing it backwards.

It is.

--
Greg

Unfortunately, most of the comments on this bug report -- including those by jmspeex, ChrisH, Gok6tm, user2037, Michael, Thomas Folz-Donahue, Greg K Nicholson, and avdd -- have nothing to do with the bug.

This bug report, like the Gnome bug report it links to, is specifically about dialogs belonging to background windows. It is not about focus stealing prevention in general. If you have suggestions for improving the focus stealing prevention algorithm, I suggest you work together on a specification with a flow chart for how it should work. Include a description of how it would differ from the existing algorithm, and examples of how it would do better. If you don't know what the existing algorithm is, research that first.

If you look at my original comment, you'll see that the reason I commented here is because someone made my earlier bug report a duplicate of this bug. So if you're not happy, find that person and tell him/her to stop doing that.