Re: Focus stealing

[Dana Jansens <danakj orodu net>]

2009/12/9 Michael T <raselmsh hotmail com>:
> Mark Tiefenbruck <mark <at> fluxbox.org> writes:
>> Either I opened it from a terminal (which can't possibly know whether
>> a command it runs will open a window) or from a keybinding (ditto),
>> and I opened it because I wanted to use it.
> Maybe a terminal can know?  I presume it can at least work out the pid of
> whatever is running in the foreground, as it displays the command line in the
> menu bar, so it should be able to notify the WM that it is willing to donate its
> focus to a window owned by that particular pid or a child.

It's possible for a shell to use the startup notification protocol
when running things, but it can get quite shadey when you are running
things which will run others things (like other terminals), since the
startup notification stuff is passed along in the environment.  It's
not backwards compatible with older applications at all.

I think I've seen something about a module for zsh that did that, or something..

> I hadn't really thought about the keybinding case.  If it is the WM that is
> starting the applications then it can immediately give the focus to the
> not-yet-created application, but as soon as the user clicks on something else
> remove it and not give it back.  I suppose this is my real complaint - it
> happens so often that I start several new applications when I first boot up,
> some of which pop up password boxes.  Then the others pop up at random times and
> steal my focus.  In the worst case, I once typed a password into a public chat
> room.  I am OK with a new window being given the focus in advance as soon as it
> is started, but as soon as I have focussed something else, I want it to loose
> that privilege.

Proper focus stealing prevention requires correct communication
between the WM and all the applications involved, in not entirely
trivial ways.  Very few applications get it all right still, if they
support it at all.

The real problem is that the WM does not have any control over focus.
It can move it, but it can't prevent other applications from moving it
too.  Really it can just watch and react to where the focus is, being
unable to predict at all.  Fixing that requires a focus redirect,
similar to substructure redirect, which would be an extension of the X
protocol and server.  Anything else will likely be full of the same
problems, or race conditions, as it requires a lot of communication
and cooperations between all windows on your screen.

Your suggestion of a "focus can get stolen now" indicator leaves a lot
of openings for misbehaviour/races.  Focus can be stolen by whom?
More than one window may be opening.  I would prefer a hint on new
windows mapping such as _NET_WM_FOCUS_FROM, with a window ID, and if
window with that ID currently has focus, then the new window takes it.
 However, there is nothing stopping application writers from just
sticking the ID of the current window in that property and always
taking focus.  Many GTK+ applications already call _NET_ACTIVE_WINDOW
on themselves after mapping, causing the WM to give them focus and
take it away from other windows, for absolutely no reason, regardless
of focus settings for "new windows" in the Window Manager.

I guess my point is that I think this requires a more thought out
response than one hint on a window, and an expectation that everything
is going to behave correctly.

Dana