Comment 17 for bug 54741

Personally, I'm less concerned about the potential security issue than with the general user-interface problems the lack of strict mouse-focus produces. Examples I've experienced:

* I have a data analysis package that creates about a dozen windows, at a rate of around one every 2 seconds. The focus-stealing by these output windows (which display plots of data) means that the input is effectively disabled (e.g., I can't be typing in a terminal) for an extended period of time while this happens. Ugh.

* If I'm typing in some app, e.g., a text editor, and a dialog box (e.g,. a mail notification, battery status, calendar event, etc.,) pops up and gets focus, there is a strong chance that the dialog will be dismissed before I even realize it was there, let alone decide what the appropriate choice is. Oops! This is especially true since most dialogs have a default choice which is activated when the spacebar is pressed. In typical typing, every ~6th character is a spacebar.

* Sometimes I want to close a bunch of windows by pointing the mouse at them and hitting Alt-F4. I've more or less given up on doing this, though, because sometimes when one window is closed, the focus switches to some window other than the one under the mouse, and if I don't notice immediately I close that window instead of the one I wanted to. Oops!

* Sometimes I'm running a commandline app that generates output windows. Typically these output windows do not process keystrokes or mouse events. However, the do get the focus when they are created, so every time I create one from the terminal, I need to wave the mouse off the terminal and back onto it before I can continue working. Yuck.

Generally, it's simpler and more intuitive to tell a new user, "point the mouse at a window and type into it" than "point the mouse at a window and type into it, unless a new window has been created, in which case your typing will go to that one, unless the window manager has decided not to move the focus for some reason, so really you need to wave the mouse around and then point it into the window you want to be typing into every time the window manager does something". Yes, it's sometimes convenient to have the focus go to a newly-created dialog ***which is a child of the app that currently has focus*** , but the cost of that minor convenience seems excessive if it means the focus will go to (almost) every newly-created window.

Many of the Metacity themes use only subtle visual indicators of window focus, e.g., the colors of the titlebar buttons or text. This makes it especially important not to surprise the user by changing the focus without being explicitly requested to. (As it stands, I always pick window frame themes that make large, obvious changes to the titlebar and border colors to partly work around the Metacity behavior).