Created attachment 16990 [details] [review]
Proposed patch

But the verbose message (which you keep in the patch) 
specifically says it's important to end the grab prior to 
trying to focus the window. That fixed some other historical 
bug. Are you sure this works?

Are you using mouse focus or click to focus?

Hi Havoc:  the problem we are seeing is with keynav.  Mouse focus
doesn't exhibit this symptom.

I have tried it with both mouse focus and click to focus and it seems
to work well in both cases.

I cannot find any reference to a bug which requires the other
ordering.

So what goes wrong here? Guessing - You alt+tab while gedit is
focused, causing focus out on gedit due to the grab; releasing the
grab returns focus to gedit; metacity then focuses the new window,
gnome-terminal.

If you try to focus gnome-terminal while you have the grab, I just
would not expect that to work or do anything. I need to understand
this better.

As an aside, metacity's idea of focus does not quite map to 
X's idea of focus; the task list is using metacity's idea. 
(_NET_ACTIVE_WINDOW property on the root window IIRC).
There's a bug "make focus tracking correct and reliable" that 
talks about this a bit. Using _NET_ACTIVE_WINDOW may be 
what you want if you're tracking user-visible focused window.

that's not quite what happens: what happens (it seems) is:

* focus out on gedit when grab goes active;
* focus in on terminal when metacity focussed it;
* focus in on gedit when grab is released (!)
* focus out on gedit (!)

- Bill

That's not the same order as in padraig's initial report - 
does the X server even send "in" before "out" ever? I thought 
you always got the out first.

Anyhow, cc'ing X focus experts.

I don't think the sequence Bill posted is quite possible,
though I don't know how he is tracking focus events.

It's quite important to pay attention to the mode and
details fields of focus events; you can certainly
get sequences like:

 Window A; FocusOut; mode = NotifyGrab
 Window A; FocusOut; mode = NotifyWhileGrabbed
 Window B; FocusIn;  mode = NotifyWhileGrabbed
 Window B; FocusIn; mode = NotifyUngrab

that don't look like paired In/Out.

Havoc,

If I understand correctly you are surprised that XSetInputFocus seems
to work if called before XUngrabKeyboard. It works for me, on Solaris.
I do not have a linux environment to check.

I do not agree with the Bill's ordering above. In fact, I have no way
of knowing the ordering of the focus events as they do not have
timestamps.

I am trying to figure out whether we can avoid the FocusIn/FocusOut
pair of events for the window which is losing focus.

We are connecting to focus-in-event and focus-out-event signals for
GtkWindows to get notification of which window has focus.

We would really like to have this patch applied.

It prevents spurious FocisIn and FocusOut when using Alt+Tab to switch
windows. It does not seem to cause a regression on Linux or Solaris.

What was the historical bug which required the grab to end before
trying to focus the window?

Marking AP2 to reflect a11y team's assessment of a11y impact.

This is actually a fairly significant blocker, marking AP1.

Havoc - you agreed at GUADEC that we could apply Padraig's patch and
monitor closely for regressions (though you also suggested an
alternative fix for the long-term which would alleviate the need for
Padraig's patch).  Is that still OK? e.g. can we apply Padraig's patch
for the time being?  thanks.

Patch comitted to CVS HEAD.