GNOME Bugzilla – Bug 662493
Put focus on Log Out and Power Off dialog with appropriate button
Last modified: 2012-03-12 20:10:39 UTC
When using the "Log Out..." option from the Status menu the resulting confirmation dialog does not get focus, nor does the Log Out button. In other cases, similar dialogs always get focus right after the user action. It would be more efficient if the Log Out button of the confirmation dialog gets focus right after the user clicks on the log out option in the Status menu. Now you have to navigate to it with your mouse while you want to be there anyway. Putting focus on the button allows you to hit enter on your keyboard right away.
The same goes for the Power Off... dialog by the way.
Created attachment 199970 [details] [review] PopupBaseMenuItem: don't steal key focus from any actor Grab the key focus only if the current holder is in our focus group. Otherwise we might end up stealing the key focus from totally unrelated actors elsewhere in the UI. In particular this avoids diverting the key focus away from shell modal dialogs after activating a menu item. This happens because the menu item gets a notify::hover after the modal dialog grabs the focus.
*** Bug 664039 has been marked as a duplicate of this bug. ***
Created attachment 201501 [details] [review] PopupBaseMenuItem: grab key focus only if it's already in our focus group -- Rebased on master and wrote a clearer commit summary.
Created attachment 205498 [details] [review] boxpointer: Prevent spurious input events while animating The hide animation causes hover notifications for the actors inside the boxpointer. PopupBaseMenuItems, in particular, grab the keyboard focus on hover notifications to enable keyboard navigation on menus. This, in turn, breaks modal dialogs' keyboard navigation since key focus is taken away from a just created dialog when the menu is hiding. Since input events aren't useful while menus are animating we just prevent them from propagating. -- This is a more general fix. But I'm afraid this might be an even more widespread and general problem with all kinds of animations. Maybe we should do this event muting at the Tweener level?
Review of attachment 205498 [details] [review]: Grrr, looks like my IRC "review" got lost in network flakiness :( <fmuellner> rtcm: makes sense <fmuellner> (thinking about a more general approach sounds like a good idea long-term, but for now that patch should be good)
Thanks Attachment 205498 [details] pushed as 36804a6 - boxpointer: Prevent spurious input events while animating