Re: focus stealing prevention (was Re: _NET_ACTIVE_WINDOW, revisited)

[Lubos Lunak <l lunak suse cz>]

On Wednesday 27 of July 2005 18:34, Elijah Newren wrote:
> On 7/27/05, Lubos Lunak <l lunak suse cz> wrote:
> > On Tuesday 26 of July 2005 18:54, Elijah Newren wrote:
> [Offtopic: Now that I think about it, I think I can fix Billy's
> problem by patching gdk_window_focus() to use the most recent user
> interaction timestamp whenever 0 is passed.  That'll simplify
> gtk_window_present() as well...]

 I personally think Billy's primary problem is the fact that they use 
_NET_ACTIVE_WINDOW too much. When an application shows a new dialog window it 
shouldn't do _NET_ACTIVE_WINDOW on it just in case or for the fun of it. 
AFAIK all modern toolkits keep the X focus only on the toplevel window and 
maintain their own internal focus, for good reasons. So there should be 
rarely a reason to mess with the X focus.

>
> > There are (or can be, at  least) actually two timestamps for one window -
> > the application's and the WM's. When KWin gets a request from a window
> > and doesn't get a usable timestamp with it, it uses its own timestamp for
> > the window (from the last time it detected user interaction with the
> > window, or it got last valid timestamp for it, or whatever).
>
> Oh, the "requestor's currently active window" field for
> _NET_ACTIVE_WINDOW, right?  I had never understood the reasoning for
> that.

 No. Your problem, if I understand it correctly, is that if you get a request 
that doesn't include a valid user activity timestamp, you don't know what to 
do. To solve this you can keep your own activity timestamp for the window in 
the WM. You can update it from valid timestamps you get from the app, and you 
can also update it if you detect user activity yourself (clicking on the 
titlebar or whatever). If I don't understand your problem correctly then we 
indeed might be talking about different things.

> So, am I correct in inferring that you use this as a backup in 
> case a timestamp of 0 is provided, making use of the WM's
> last_user_interaction timestamp for that window in this case?  Is
> there anything else you use it for?  (I'm having a hard time seeing a
> use for it if a nonzero timestamp is provided, but perhaps I'm just
> missing something again)
>
> Also, one of my main sticking points in understanding the currently
> active window stuff was that (correct me if I'm wrong) apps can't
> reliably know whether they have a window which is active since they
> only get notified of loss of focus after it happens.  Perhaps "the
> requestor's most recently active window" would clarify this?  Except,
> that would kind of negate the need for sending None sometimes which
> the spec allows...  hmm...

 The reasoning for the current active window is here: 
http://mail.gnome.org/archives/wm-spec-list/2003-October/msg00039.html - it's 
for the cases when an active application wants to activate another window 
that doesn't belong to that application.

 But now that you ask I'm actually unsure whether it's really needed or if 
just the timestamp could do as well. Hmm ... thinking ... well. It's a bit 
difficult to remember for me. It was quite some time ago, and being the only 
person in the world ;) had some unpleasant consequences like it always being 
me who ran into dead ends from time to time and had to try again differently 
or having nobody to really check the stuff. And, as you probably now know 
yourself, thinking about this can cause serious headache. In fact just 
yesterday I was debugging some problem related to this and I found out I was 
getting wrong results because of expecting some things about the mechanism 
that no longer were true. So it indeed may be the field is just nonsense. And 
from the log messages I cannot quite remember why it found it needed either.

 Hmm. I think I might know a reason though. Say that you have apps A and B 
running. Activate A, do something in A (that updates its user activity 
timestamp, in the app), activate B, do something in B (again timestamp update 
in the app). Now activate A just by clicking the titlebar, that makes it 
active, but the user activity timestamp in the app doesn't update, only in 
KWin. And now if A wants to activate B's window, KWin wouldn't let it, 
because A has more recent timestamp - only in KWin though, the timestamp in 
the app, and hence in the message, is old. If A adds also its active window 
to the message, KWin will see the request comes from the active window and 
will allow the activation. I guess this might have been the reason why I 
added it.

 Now, there's a rather weird details I might have missed before. Why the hell 
should A decide to activate B without any user activity leading to this? If 
the user clicks in A and that leads to the activation, the timestamp in the 
app will be correct. And the app shouldn't do the activation just for the fun 
of it. So maybe it's really nonsense.

-- 
Lubos Lunak
KDE developer
---------------------------------------------------------------------
SuSE CR, s.r.o.  e-mail: l lunak suse cz , l lunak kde org
Drahobejlova 27  tel: +420 2 9654 2373
190 00 Praha 9   fax: +420 2 9654 2374
Czech Republic   http://www.suse.cz/