RFE: Never, ever steal focus.

Gregory Maxwell gmaxwell at gmail.com
Thu Jan 7 03:43:36 UTC 2010


On Wed, Jan 6, 2010 at 1:08 PM, Adam Jackson <ajax at redhat.com> wrote:
> On Wed, 2010-01-06 at 11:23 -0600, Serge E. Hallyn wrote:
>> There is no case where I want a new window or popup to take focus.  Makes
>> for an easy algorithm.  (hitting r in mutt is not a problem :)
>
> There is no case where _you_ want this, sure.

Some people what that.
Many other people want the focus change to happen in a _few_ limited
cases where it makes sense.

Current behaviour fails to accurately predict those cases (no doubt
because, in part, the limited acceptable cases differ from person to
person), and so you get unexpected focus theft. This is bad for
everyone.

I think most people are actually in (2), in that a focus steal
directly in response to an action by the user an instant ago isn't
usually considered bad.  Detecting that seems impossible (since you
really need to measure intent, did I intend a new window to come up?).
 And even some people don't want that: I always prefer to load URLs in
the background ... click-click-click pipelining up tabs which load in
the background hiding the page load display. Fortunately that works
*fine* for me using my hacked up configuration, /except/ when firefox
pops up an alert box of any kind.

I think people are generally more comfortable with the computer when
it is highly predictable. _Never_ stealing focus wouldn't be optimal
for everyone, but at least it wouldn't be surprising.  If you cant get
it right, at least be predictable.

On Wed, Jan 6, 2010 at 4:01 PM, nodata <lsof at nodata.co.uk> wrote:
> I either start typing a password into a dialog then something steals focus
> and the password is in cleartext, or or the other way round: I start typing
> something in one apps, a password dialog pops up, and I end up typing
> non-passwords there. Ugh. Dangerous and not good.
>
> This must be solvable, not just for password entry.

In the never-steal case you can learn (through trial and error :( ) to
always click before typing a password.  In the (sometimes or always)
focus stealing case you can't even be conditioned to work with it,
unless you consider visceral terror between each keystroke that the
computer will do something unexpected causing you to type
v.e.r.y.s.l.o.w.l.y.

Both fail, one fails in a more predictable way.

If nothing else, a configuration option would be good.  Though I still
hold that the state least likely to continually produce surprise
should pretty much always be the default.


On Wed, Jan 6, 2010 at 1:41 PM, Adam Jackson <ajax at redhat.com> wrote:
> To pick an example from my daily life: Someone pastes a bugzilla URL at
> me on IRC, and I need to go scroll through it to see what they're
> talking about.

Thats pretty much the opposite of how I work. I'd rather the link
loaded in the backround so that my flow isn't interrupted waiting for
it to load.




More information about the devel mailing list