GNOME Bugzilla – Bug 53544
KEYNAV: GtkMenu, GtkMenuItem, GtkCheckBoxMenuItem, GtkRadioButtonMenuItem
Last modified: 2015-12-22 01:33:43 UTC
When a submenu has focus, pressing Esc should unpost only that submenu, and give focus back to that menu's parent menu item. (Currently all the open menus and submenus are unposted). When a top level menu has focus (and the menu has been posted from a menubar), the menu should be unposted and focus given back to that menu's title in the menubar. (Currently the menubar cannot have focus without posting any menus-- see bug #53543). Once a menu is posted, the mnemonic for each item should be active *without* having to hold down the Alt key. (Currently you have to hold down Alt+mnemonic, or risk dynamically re-assigning the shortcut for that menu item). If a menu has two items with the same mnemonic, repeatedly pressing that mnemonic (with or without Alt) should cycle keyboard focus between those items, without activating any of them. In this case, the focused item is not activated until you press Enter. When a submenu has focus, pressing left arrow should unpost the submenu and return focus to the parent menu. (Currently focus is returned but the submenu stays posted). Pressing either Shift+F10 or the Application key on an MS Windows-compliant keyboard should pop up the context menu for the currently-selected object (same as right-clicking on it after it has been selected). [Check http://developer.gnome.org/projects/gap/keyboardnav.html for any later proposals that may not have filtered through to this bug report yet]
It strikes me a little annoying if Alt-F, Escape leaves focus on the menu bar, but indeed Windows does do this... should we also be thinking about implementing the Windows behavior where Alt by itself focus the menubar? not particularly easy to do, but certainly possible at least for some future release. The comment about mnemonics and alt I think doesn't correctly describe the current behavior ... when a menu is up, no Alt is needed to activate the mnemonics in it. I think the current behavior is fine (except for locking accelerators by default, which is a separate bug.) The behavior where left in a menu unposts the menu only makes sense The handling of conflicting mnemonics and of Shift-F10 has been fixed.
My comment about Alt was only meant to imply that this behaviour needs to be available consistently. In GNOME 1.4, there was little chance of knowing in advance if pressing a key when a menu item had focus would activate the item with that mnemonic, or change the accelerator for the focused item. Therefore, to be sure of activating an item, you always had to press Alt+TitleMnemonic, followed by Alt+ItemMnemonic. Whereas folks coming from Windoze will be used to pressing Alt+TitleMnemonic followed by unmodified ItemMnemonic, so they could easily get themselves into trouble by changing accelerators unexpectedly. As you say, locking the accelerators will solve the problem, and allow the Windoze way to work unless the user has decided otherwise.
My understanding is that we have agreed that when a menu item has focus, its submenu will be posted. I am attaching a patch to make sure that focus remains on the menu bar when left or right arrow is pressed when in a submenu of a menu item in the menu bar.
Created attachment 5756 [details] [review] Leave focus in menu bar when leaving toplevel menu
Adding GNOME2 keyword to all keynav bugs per sander's request. You can filter on the phrase 'luis doing GNOME2 work' to catch all instances of this so that you can ignore them.
Found another annoying (but minor) menu keynav thing-- if you popup a menu close to the right edge of the screen, then navigate to an item on it that has a submenu, the submenu pops up to the left of the menu as there is no room to the right. However, you still have to press right-arrow to navigate into that submenu, which is counter-intuitive-- it would be good if you could press left-arrow instead in this case.
Moving non-critical or hard to fix bugs to 2.0.2
Move open bugs from milestones 2.0.[012] -- > 2.0.3, since 2.0.2 is already out.
I have fixed the following keynav issues in the menus:- a) When a submenu has focus, pressing left arrow should unpost the submenu and return focus to the parent menu. b) When a submenu has focus, pressing Esc should unpost only that submenu, and give focus back to that menu's parent menu item. c) When a top level menu has focus (and the menu has been posted from a menubar), the menu should be unposted and focus given back to that menu's title in the menubar.
Created attachment 8015 [details] [review] Patch with the above stated fixes
Not going to do this type of major change for 2.0.x. (Currently you never have the situation where the focus is on a item and the submenu underneath it is unposted, so doing this could cause breakage in unexpected places.)
(Just adding some "should we fix it" comments in response to Owen's recent buglist email) Currently our 'Esc' behaviour when a menu or sumenu is posted is the same as Mac but different from Windows. Windows does what parts (b) and (c) of Raj's patch above implements, i.e. returns focus to the parent menu or to the menu title. I don't think is a major issue since the user can currently use the arrow keys in gtk to achieve the same results, so I suspect this is probably a wontfix for 2.2.
We need to decide whether this is a WONTFIX ever, or something that we need to work on for a future release.
Updating status_whiteboard field to reflect A11Y team's assessment of accessibility impact.
Well, from a familiarity point of view I guess more people would expect the Windows-like behaviour just because more people have used Windows (which IIRC also has more in common with the CUA standard here). But usability-wise I'm not sure there's anything significant between them, except that the Windows way is potentially less error-prone until you learn the behaviour-- it's never likely to unpost more menus than you thought it would, which can happen with the Mac/gtk way.
Apologies for spam... marking as GNOMEVER2.3 so it appears on the official GNOME bug list :)
This patch has a problem in <file://cvs.gnome.org/cvs/gnome/gtk+/gtk/gtkmenushell.c>: aew@duende:~/Projects/GNOME/CVS/gtk+$ patch --strip=1 < /home/aew/showattachment.cgi patching file ChangeLog Hunk #1 FAILED at 1. 1 out of 1 hunk FAILED -- saving rejects to file ChangeLog.rej patching file gtk/gtkmenushell.c Hunk #1 succeeded at 28 with fuzz 2. Hunk #2 succeeded at 1070 (offset 23 lines). Hunk #3 succeeded at 1102 (offset 37 lines). Hunk #4 FAILED at 1166. 1 out of 4 hunks FAILED -- saving rejects to file gtk/gtkmenushell.c.rej The contents of gtkmenushell.c.rej: *************** *** 1160,1173 **** gtk_real_menu_shell_cancel (GtkMenuShell *menu_shell) { /* Unset the active menu item so gtk_menu_popdown() doesn't see it. */ gtk_menu_shell_deselect (menu_shell); - - gtk_menu_shell_deactivate (menu_shell); - gtk_signal_emit (GTK_OBJECT (menu_shell), menu_shell_signals[SELECTION_DONE]); - } static void gtk_real_menu_shell_cycle_focus (GtkMenuShell *menu_shell, GtkDirectionType dir) { --- 1166,1184 ---- gtk_real_menu_shell_cancel (GtkMenuShell *menu_shell) { /* Unset the active menu item so gtk_menu_popdown() doesn't see it. */ gtk_menu_shell_deselect (menu_shell); + + if (menu_shell->parent_menu_shell) + gtk_widget_hide (GTK_MENU (menu_shell)->toplevel); + else + { + gtk_menu_shell_deactivate (menu_shell); + gtk_signal_emit (GTK_OBJECT (menu_shell), menu_shell_signals[SELECTION_DONE]); + } + } static void gtk_real_menu_shell_cycle_focus (GtkMenuShell *menu_shell, GtkDirectionType dir) {
Need to decide on this early for the 2.6 cycle
Apologies for spam-- ensuring Sun a11y team are cc'ed on all current a11y bugs. Filter on "SUN A11Y SPAM" to ignore.
Comment on attachment 8015 [details] [review] Patch with the above stated fixes The patch in attachment #8015 [details] needs work. a) Simply calling gtk_widget_hide/show on the toplevel is not the right way to popup/popdown submenus b) The patch seems to always unpost the menu containing the deepest selected menuitem, even if there is a further submenu.
Not going to get to this for 2.6.0.
Apologies for spam... ensuring Sun a11y folks are cc'ed on all current accessibility bugs.
Patch 5756 doesn't apply cleanly. Reviewing it would take little time. (Working on http://mail.gnome.org/archives/gtk-devel-list/2007-March/msg00148.html)
not going to get to it at all, it seems