GNOME Bugzilla – Bug 114037
Spurious Focus events when switching windows
Last modified: 2004-12-22 21:47:04 UTC
When switching from gedit window to gnome-terminal window using Atl+Tab the following events occur: FocusOut on gedit FocusIn on gedit FocusOut on gedit FocusIn on gnome-terminal We would like to eliminate the FocusIn and FocusOut pair om gedit. Patch to follow.
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.