GNOME Bugzilla – Bug 153220
"focus follows mouse" after showing "log out"
Last modified: 2004-12-22 21:47:04 UTC
Please describe the problem: - Set metacity to 'click to focus' - Select a nautilus icon - Select Actions->Log Out - Click Cancel - Move the mouse around The nautilus window is now focused only when the mouse is inside it. Steps to reproduce: Actual results: Expected results: Does this happen every time? yes Other information:
Strange. Maybe gconf quit or something? Or metacity restarted or exited?
I can duplicate, but none of the windows appears to have focus (i.e. the titlebars of all applications remain shaded). The only way I can tell which window has focus is to start typing and then noticing that the keystrokes go to the window containing the mouse. It appears that neither gconf or metacity have restarted (gconfd has the same PID afterwards, which I assume means it's the same instance; I ran 'metacity --replace' from a terminal and it hadn't exited after I cancelled). gtk+/gdk/gdkevents-x11.c, in the function gdk_event_translate, has some code to focus the window with a comment of "Handle focusing (in the case where no window manager is running" -- perhaps gtk+ thinks the window manager isn't running anymore?
Sounds like we're in PointerRoot mode and metacity isn't handling events, as you describe it. Maybe metacity just gets wedged after a cancelled session save? Maybe a stuck grab?
Actually it looks like Metacity is handling events. I can use Alt-Tab to focus the next window in the MRU list, or Ctrl-Alt-Arrow to switch workspaces. Doing either of those things or clicking on any window ends the "focus-follows-mouse" weirdness. This problem doesn't seem to affect sloppy or mouse focus at all; the window under the pointer after clicking cancel gets an EnterNotify and the window becomes focused (meaning that it receives keystrokes _and_ the titlebar is colored to cue the user that is has focus). I tried getting a log, and noticed that following the panel losing focus, the last focus event appears to be the following: EVENTS: FocusIn on root 0: detail: NotifyInferior mode: NotifyNormal serial 6149 FOCUS: Focus in event received on root window 0x60 mode NotifyNormal detail NotifyInferior I'm curious as to why the root window is focused somehow instead of Metacity focusing the default (i.e. MRU) window.
Maybe check if the logout dialog sets focus to the root window - I guess that could cause the behavior described... but clicking on a window to focus it should still work and unbreak things.
Yes, you are right that clicking on a windwo to focus it will work and unbreak things. I tried looking for something that might be setting the focus to the root window. I found the following function calls that look to be of interest in gnome-session/gnome-session/logout.c: XGrabServer (GDK_DISPLAY ()); XSetInputFocus (GDK_DISPLAY (), GDK_WINDOW_XWINDOW (box->window), RevertToParent, CurrentTime); XUngrabServer (GDK_DISPLAY ()); I figured that these lines had to be at fault and tried playing around with things...but, um, I seem to have come up short. Removing the XSetInputFocus call (which doesn't seem to be needed--there are pointer and keyboard grabs immediately preceding it) does prevent the "keyboard events go to the mouse window" behavior, but nothing I tried could get the correct window (or even any window) to be really focused.
In case it wasn't clear, those function calls weren't contiguous--I was just listing some functions I saw.
I guess if an override redirect window (as the logout dialog I'm pretty sure is) has focus, and gets closed, then the focus will revert to root window. Because the window is override redirect there's no MetaWindow and metacity won't do its usual "focus another window when a window closes" thing. The obvious fix is to have metacity monitor the root window for focus in events, and focus default window when the root window gets focused. This could have odd side effects, of course, as all focus related changes seem to...
Created attachment 32131 [details] [review] Detect root window being focused in this situation and focus the default window This patch fixes the issue; it doesn't seem to have any ill-side effects that I can see. It depends on the patch in bug 152000 being applied first. (...due to context, I guess it kind of depends on the patch in bug 125492 as well).
Comment on attachment 32131 [details] [review] Detect root window being focused in this situation and focus the default window What if the root window is the only window? Will this result in an infinite loop?
No, it won't. Metacity creates a dummy window known as the no_focus_window. In all code paths through meta_workspace_focus_default_window which the patch calls, if no valid MetaWindow can be found that needs to be focused, then the no_focus_window is focused.
Comment on attachment 32131 [details] [review] Detect root window being focused in this situation and focus the default window ok, I wasn't sure if we would ever focus the root window in that function, but sounds like we should be fine. Since I can't think of any reason why the root window should ever be focused, I don't see a problem with this. Accepted pending changing the though_shalt thing.
Created attachment 32226 [details] [review] Slightly updated patch The other three patches I just applied necessitated an update to this patch. Here's the updated version that I applied to CVS.