GNOME Bugzilla – Bug 123366
The visual bell changes my focus
Last modified: 2005-02-25 20:14:29 UTC
With the visual bell (full screen one) the focus changes to the window where I have the mouse cursor. I think it should remember the window that has the focus before the screen movement instead of follow the normal window manager preference. (My preference is that the focus follows the mouse cursor, but sometimes I change it with Ctrl+Tab and the mouse cursor is not inside the window with focus)
Moved to metacity, that's the application that implements the visual bell
We can reset the focus after the visual bell completes, I guess. Could be tricky with race conditions. Need output-only windows. ;-) Or better I think there's some code to ignore certain EnterNotify events in there already, so maybe could just use that.
should be able to use meta_display_increment_focus_sentinel and meta_display_decrement_focus_sentinel before and after the visual bell to handle everything perfectly. Assuming we have a timestamp for the bell event.
actually that's not quite right, but you should be able to simply add a meta_display_increment_focus_sentinel right before the XFlush in meta_bell_flash_screen and then all EnterNotify events will be ignored on that display until the PropertyNotify for the metacity_sentinel. That should give us what we want, no?
Created attachment 37942 [details] [review] Fix the problem The other recent visual_bell bug reminded me about this one. Anyway, as Rob says, the metacity sentinel can fix this. However, using it will introduce a race condition for mouse & sloppy focus modes (if the user moves the mouse quickly enough into a new window at the time the visual bell occurs then the window won't get focused when it should; I have verified I can trigger this race and get the wrong window focused in that case). Therefore, the metacity sentinel should only be used when mouse_mode is false (see bug 167545); that will handle the case that Carlos is worried about. There are a couple cases that this approach can't handle, but they're in corner cases that are inherently busted anyway: (1) if mouse_mode is false but the user decides to move the mouse real quick, the same race condition exists (but users mixing keynav and mousenav are screwed anyway, as pointed out in bug 167545), (2) there are a couple ways to break mousenav invariants without mouse_mode being false (new window or use of the tasklist or window selector applet); in these cases the sentinel won't be set and the window under the mouse will gain focus. The proposal in bug 152004 will solve the new window case. In the other two cases, users get what they deserve for using mousenav and requesting that a window not under the mouse be activated.
Created attachment 37946 [details] [review] Don't forget to ignore LeaveNotify events too So I've been running with this patch and the annoying visual bell turned on for a while in order to catch any problems. Looks like we forgot to ignore LeaveNotify events too, meaning that in mouse focus mode we can get windows to get unfocused when in keynav mode. In general, LeaveNotify events should be ignored when EnterNotify ones are, so this patch just makes that change along in addition to changes from the previous patch.
Comment on attachment 37946 [details] [review] Don't forget to ignore LeaveNotify events too Seems plausible.
committed.