GNOME Bugzilla – Bug 53709
KEYNAV: GtkButton
Last modified: 2007-01-06 03:39:21 UTC
If a GtkButton shares the same mnemonic as another control in the same context, the button should not be activated when it is given focus by using that mnemonic. In this case, activation should need to be done explicitly by pressing Spacebar when the button has focus. (This is an instance of the general behaviour recommended for Gtk 2.0 for clashing mnemonics-- repeatedly pressing that mnemonic should cycle focus through all widgets that share the mnemonic, but not activate any of them). When a GtkButton has focus, Spacebar should activate it. Pressing Enter should always activate the window's default button if it has one, or do nothing if it doesn't have one, regardless of which control currently has focus (be it a GtkButton or not). The only exception to this is when the control that does have focus over-rides Enter for its own purposes, e.g. a multi-line text field. When a control that doesn't accept keyboard input has focus (e.g. textfields, buttons, tree/list-derived widgets), it would be nice if all mnemonics in that the current context were active whether or not the Alt key was held at the same time. At the very least, though, in any message box, it should be posisble to select any of the command buttons just by pressing the underlined character on any of those buttons, unmodified. [Check http://developer.gnome.org/projects/gap/keyboardnav.html for any later proposals that may not yet have filtered through to this bug report]
>Pressing Enter should always activate the window's default button if >it has one, or do nothing if it doesn't have one, regardless of which >control currently has focus NB This is still open to debate, and is currently being discussed on gnome-accessibility-list and gtk-devel-list.
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.
Put on the 2.2 milestone for the issue of whether the default should move to the currently focused button.
Created attachment 8333 [details] [review] patch that fixes: "If the current control doesn't accept keyboard input , then mnemonics should be accessible without the Alt key"
Owen, what's the status of Pasu's patch, have you ever reviewed it? If it's acceptable I think it's really worth consideration for 2.2... Windows already offers this functionality and it's very useful for dismissing alerts and navigating simple dialogs. (And it's orthogonal to the default button debate that the rest of this bug is concerned with).
Marking AP3 to reflect a11y team's assessment of a11y impact.
Bumping up the priority to make sure I look at the patch before 2.4.
Apologies for spam... marking as GNOMEVER2.3 so it appears on the official GNOME bug list :)
Issues with the patch: - For GTK+-2.4, we've exported all the internals of gtk_window_key_press() so someone can provide their own customized behavior. This introduces private parts of gtk_window_key_press() again unless we make more API additions. (Which we can't do at this point) Of course, customized key press handlers wouldn't work any worse than they did without the change, just less consistently with other GTK+ windows - The patch hardcodes GDK_MOD1_MASK - There is a bunch of code duplicated between activate_key and activate_key_without_modifiers. - I think this handling should be after *everything* else, include the binding set for the toplevel window; even so, there is potential for breakage, because an application might have connected to the window with g_signal_connect_after(). I'm going to attach a version of the patch with most of the above issues cleaned up; it does make things feel a lot nicer. The g_signal_connect_after() issue means however that it probably can't go in until GTK+-2.6. (Even then, it's a bit of a scary quasi-incompatible change, but at least we have some time to see how much it breaks...)
Created attachment 25545 [details] [review] My version of patch
Comment on attachment 8333 [details] [review] patch that fixes: "If the current control doesn't accept keyboard input , then mnemonics should be accessible without the Alt key" Obsoleted by Owen's patch, marking as such.
Apologies for spam-- ensuring Sun a11y team are cc'ed on all current a11y bugs. Filter on "SUN A11Y SPAM" to ignore.
Created attachment 33291 [details] [review] Another proposed patch. Here is another proposed patch. Owen: I'm not sure whether it is useful to handle this in the window class, since it only seems to affect message dialogs. My implementation does it directly in the message dialog class and has way less LOC. testgtk seems to like it.
The behavior should apply to *any* window without editable text fields, not just ones that happen to be implemented as a GtkMessageDialog. Though I have trouble remembering my patch 6 months later, I think it was basically OK, except that it was blocked by the 2.4 API freeze. I think we should be be able to commit it now for 2.6.
2004-11-02 Matthias Clasen <mclasen@redhat.com> * gtk/gtkwindow.c (gtk_window_activate_key_after): As a last stage in GtkWindow key press handing, try adding window->mnemonic_modifier to event->state and see if it matches a mnemonic. (#53709, based on a patch by Pasupathi Duraisamy, patch by Owen Taylor)
This change broke Epiphany's typeahead find: Steps to reproduce: 0) Start epiphany, load a page 1) Type 'F' (or '/F', if you disabled typeaheadfind autostart) This will search for 'F' but also open the File menu.
Well, that's clearly a Epiphany bug. If you consume a keystroke, you have to return TRUE from your key press handler to indicate that. But it might indicate that this change isn't sufficiently compatible :-((
I should have said, more precisely, that this broke mozilla's typeaheadfind, when embedded in Epiphany. Epiphany doesn't do anything here. I'm going to try to find the cause in mozilla code. > But it might indicate that this change isn't sufficiently compatible :-(( Yes.
Take a look at https://bugzilla.mozilla.org/show_bug.cgi?id=268171
*** Bug 73431 has been marked as a duplicate of this bug. ***
Apologies for spam... ensuring Sun a11y folks are cc'ed on all current accessibility bugs.
The mozilla problem has been fixed in the meantime. Closing this.