The combination of focus-follows mouse and keyboard navigation
(which it sounds like you are using) is always going to
be a bit unreliable ... if you use keynav a lot, you really
should consider using click to focus.

I'll assign this to metacity though to let Havoc close it
if he thinks it is appropriate... GTK+ doesn't really have
anything to do with this.

As Owen says, keynav is just screwed with focus follows mouse, because
the focus has to do with your mouse position, which is not interesting
when doing keynav.

I don't really have a clue how to fix this so I'm marking wontfix. 
If someone can come up with a patch that fixes it without breaking 
something else I'd take the patch.

In that case, maybe the solution is to have metacity warp the mouse
pointer to the window you alt-tab to, at least when focus policy is
'follow mouse'. Because, as you say, in this policy it's not clear
what it means to have a window in focus that isn't pointed to by the
mouse.
I don't know if the option already exists (I think Sawfish had it).

*** Bug 145387 has been marked as a duplicate of this bug. ***

Ok, so the problem comes from the following: gtk+ does a grab when showing
override redirect windows (such as menus or entrybox completions mentioned in
bug 145387), X generates EnterNotify and LeaveNotify events for grabs and
ungrabs, and metacity gets those extra events.  The fix is as simple as ignoring
EnterNotify and LeaveNotify events when they are caused by grabs.  Surprisingly
enough, someone already noted that this was needed for LeaveNotify events and
put the code into Metacity, but somehow missed doing the same thing for
EnterNotify events.  I'll attach a patch in a minute.

Created attachment 31253 [details] [review]
Ignore EnterNotify events from grabs

Ignoring the events doesn't work ... the user might move the mouse
from one toplevel to another while the menu is up.

I understand your claim, but I disagree with it.  I think that's the whole point
of a grab...

Currently:
  A) If I activate a window menu, and move the mouse to a different window
     from where it started when the menu was activated, that other window
     doesn't get focus until I close the menu.  To me, that feels buggy.  So
     this is /another/ reason I don't like the current behavior.
  B) If I have the mouse in a different window than where I activate a window
     menu, and then leave the window menu (without moving the mouse), the
     focus surprisingly reverts to the first window.  (This case is the one
     that this bug report is about)
With my patch:
  - For case (A), the other window doesn't get focus IF I use keynav (e.g.
    Escape) to close the menu (it does work fine if I click with the mouse
    in the other window to close the menu in the first window).  This may not
    be optimal, but it is consistent with current behavior in Gnome (e.g.
    when application menus are open, one can't use Metacity keybindings to
    switch workspaces).
  - For case (B), the focus doesn't revert to the other window--i.e. things
    work as expected.

So, my opinion is that I got two birds with one stone.

If people disagree with me on (A), we can cc usability and see which case they
think is a larger use case out of (A) and (B).  (Personally, I think case (A) is
a vastly smaller usage case than (B) usability-wise and that the need for
correct behavior for (B) would trump that for case (A))

If you cc the usability people they will just say "use click to focus, it
doesn't have all these complex issues" ;-)

Maybe...but perhaps if I list my own usability rationale, they could read it and
state whether they thought it had any holes in the logic.  I guess I should do
that anyway, so let me take that track:

Owen, as always, correctly points out one of the side-effects of my patch.  This
means that there are bugs for two different situations: (A) when the user moves
the mouse into a different window while a menu is up, and (B) when the user
makes use of keynav while the mouse is in a different window.

My patch fixes the problem in situation B, and changes the behavior in situation
A in a way that we perhaps don't yet agree whether it introduces (er, extends) a
bug or fixes one.  I could take some more time and explain usage cases for why I
believe that the new behavior for situation A isn't a bug (feel free to let me
know if you'd like to hear this), but for the sake of argument let's just say
the patch extends the bug in situation A.  Given this assumption, we have a
trade-off and we need to consider the usability ramifications of both bugs:

First, situation B without my patch:  If a sloppy/mouse focus user attempts to
use key navigation to bring up an override redirect window (menu, tab-completion
field for an entry, etc.), they must move the mouse to an appropriate location
(which isn't necessarily an easily thing to learn how to do) each and every time
they bring up such a window.  Effectively, keynav usage _requires_ that the
mouse constantly be moved in order to work correctly; i.e. the user cannot use
just the keyboard for a while (Note that I often use the mouse for a while, then
decide to just use the keyboard for a few hours, etc.)

Second, situation A with my patch: If a sloppy/mouse focus user brings up an
override-redirect window *and* moves the mouse to a different window *and* uses
a keystroke (instead of a mouse click) to dismiss the override-redirect window,
then the window they moved the mouse to won't have focus.  To get it to have
focus, they will need to click on it.  Clicking should be relatively easy since
they just barely used the mouse and so they likely already have their hand in
place.  Also, clicking on a window to give it focus is a much easier behavior to
learn than the fix for situation B where one has to learn that they need to move
their mouse and learn where they need to move it.  Also, since triggering this
bug requires the use of both the keyboard and the mouse, it is less likely to be
triggered than the situation B bug which only requires use of the keyboard. 
Finally, for this situation, users are perfectly able to use just the keyboard
for a while.

So, even if we assume that my patch introduces a bug, isn't it significantly
enough better than the current problems that we should apply it (after code
freeze is over, of course)?  Or is there something I'm missing in my arguments
and rationale?  Also, as stated above, I'll provide usage cases and a more
detailed explanation for why I believe the new behavior for situation A isn't a
bug, if anyone is interested.

It's tough for me to feel confident we've thought about all the cases *other*
than menus... there are grabs in other cases, no? What kinds of bugs could we
fix/introduce in those?

Sure, that's fair.  See bug 145387 and bug 147699 for two examples.  In both
cases, the exact same side-effect bug is fixed/introduced as for this case. 
Also, it's interesting that in those two cases, the current behavior is actually
worse than for menus, because the focus can be lost *while* the user is trying
to still use the entry instead of just when the user has finished using it.

I can't think of any cases where we'd introduce any different bug
fix/introduction than for these cases, but I'll try to think of other situations
where grabs occur and grep through some code to try to determine any that might
not be occurring to me right now.  Of course, gtk+ hackers would be more aware
of the various grab cases than me, so I'm going to cc them (yeah, I know Owen is
already cc'ed, but he's a busy guy...)

Also, I thought of a fairly succinct way to describe why I think the additional
change is a bug fix rather than a bug introduction:  If the user opens the menu
and then moves the mouse into the other window, that shows intent to use the
other window.  However, the user can continue using the menu because of the
grab.  If the user does so (using the arrow keys to highlight different menu
entries, etc.), then it shows intent to use the original window instead of the
window where the mouse is--and thus that window should retain focus.  Keys such
as escape (which dismisses the menu) are just one example of this interaction
with the menu that shows continuing usage of that original window.

I guess it makes sense to me to just ignore all the EnterNotify from a grab;
it's as rational as any of the other busted-ass heuristics involved in mouse
focus modes ;-)

We should mention this bug, and the two examples you mentioned, in rationales.txt 
as additional stuff to point to when people don't understand the claim that
mouse focus is full of broken heuristics to make keynav usable.

Okay, since I already have a bug open for updating rationales.txt (bug 150300),
I'll update my patch there to include this.

I went ahead and committed.