After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 302057 - Keys for <default> and Cancel should be Enter and Escape, and nothing else
Keys for <default> and Cancel should be Enter and Escape, and nothing else
Status: RESOLVED OBSOLETE
Product: gnome-devel-docs
Classification: Applications
Component: hig
unspecified
Other Linux
: Normal normal
: ---
Assigned To: gnome-devel-docs maintainers
gnome-devel-docs maintainers
: 315047 (view as bug list)
Depends on:
Blocks:
 
 
Reported: 2005-04-26 14:55 UTC by Matthew Paul Thomas (mpt)
Modified: 2021-07-05 10:53 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Matthew Paul Thomas (mpt) 2005-04-26 14:55:56 UTC
Distribution/Version: Ubuntu 5.04

Currently the HIG specifies that Enter *must* activate the default button in
information alerts, *may* activate the default button in error alerts, *must do
different things* depending on which control is focused in authentication
alerts, and that "Return" (not Enter) *may* activate the default button in
dialogs. It specifies nothing in particular for the Escape key (bug 124902).

At the same time, the HIG says to "Give all labeled components an access key
(underlined letter), with the exception of toolbar controls"
<http://developer.gnome.org/projects/gup/hig/draft_hig_new/input-keyboard.html#choosing-access-keys>.
Usually developers choose C for "Cancel" or and O for "OK".

This is a wee bit of a mess. Because the support of Escape and Enter is not
compulsory, people cannot be sure whether those keys will work for a particular
alert or dialog. So they'll either hesitantly try them, slowing them down, or
they'll start using access keys all the time, slowing them down. (Alt+someLetter
is (1) more keys, (2) smaller keys, and (3) less predictable.) Giving those
buttons access keys also prevents (for example) C or O from being used as the
access key for *any* control in *any* tab of *any* panel of the same dialog.

I suggest fixing all this with the following wording, distributed among HIG
sections as necessary.

    In any alert that has only one button, that button should be labelled
    'OK'. Enter (and also Ctrl+Enter) should activate this button. Do not
    also give it an access key, as that would slow people down.

    In any alert or dialog that has two or more buttons, Escape should
    activate the "Cancel" button. Enter should activate the main action
    button, unless a multi-line text field is focused (and Ctrl+Enter should
    activate the button regardless of focus). Do not also give either of
    these buttons access keys, as that would slow people down. (These
    guidelines apply only to alerts and dialogs, not to instant-apply
    windows.)

    As special protection, Enter should not activate the main action button
    if the resulting action is highly destructive (for example, erasing a
    disk). In these cases do not make Enter do anything else either, as
    people may press it expecting it to work.

    In a progress window, Escape should activate the only button in the
    window ("Cancel" or "Stop"). Do not also give it an access key, as that
    would slow people down.
Comment 1 James Bennett 2005-04-27 21:51:59 UTC
I'd agree with binding Escape to the 'Cancel' button, but not with forcing Enter
to always activate the main action. It'd break familiarity (every system I can
remember using has (mostly) followed the convention of "Enter activates the
focused control"), and likely cause confusion among users who don't understand
why, when they tab to the control they want and press Enter, GNOME is doing
something else instead.
Comment 2 Matthew Paul Thomas (mpt) 2005-10-08 02:13:42 UTC
In Mac OS X, Enter always activates the default button, not the focused 
button. The focused button is activated by Space, and indicated by a focus 
ring (very different from the solid blueness of the default button).

The current GNOME behavior cannot work well for any theme that makes the 
default button look unmistakably different from other buttons: for that 
different appearance to bounce around as the focus changed would be jarring.
Comment 3 Matthew Paul Thomas (mpt) 2008-07-26 19:13:45 UTC
Since I reported this bug, Microsoft has partly adopted the guidelines I proposed. (Mac software already follows them, though as far as I know the existence of access keys has never been acknowledged in Apple interface guidelines.) The Windows Vista User Experience Guidelines say: "Don't assign access keys to OK and Cancel buttons, because Enter is the access key for the default button (which is usually the OK button), and Esc is the access key for Cancel. Doing so makes the other access keys easier to assign." <http://msdn.microsoft.com/en-us/library/aa511453.aspx#labels>
Comment 4 Paul Bolle 2008-12-17 12:08:31 UTC
*** Bug 315047 has been marked as a duplicate of this bug. ***
Comment 5 Allan Day 2014-09-30 13:55:12 UTC
I've added recommendations for always binding return and escape:

https://git.gnome.org/browse/gnome-devel-docs/commit/?id=f6e60f87203ad4e74fe1da262735aa8e3c375fd0

The only part of this bug that remains (if I'm following correctly), is whether mnemonics should be provided for keys that are already covered by return/escape.
Comment 6 Lasse Schuirmann 2014-12-18 08:37:35 UTC
(In reply to comment #5)
> I've added recommendations for always binding return and escape:
> 
> https://git.gnome.org/browse/gnome-devel-docs/commit/?id=f6e60f87203ad4e74fe1da262735aa8e3c375fd0
> 
> The only part of this bug that remains (if I'm following correctly), is whether
> mnemonics should be provided for keys that are already covered by
> return/escape.

IMO they should be provided. It is not in all cases obvious that return/esc is the way to go so if the user explicitly presses alt to see the mnemonics, we should show him some for every button.
Comment 7 GNOME Infrastructure Team 2021-07-05 10:53:47 UTC
GNOME is going to shut down bugzilla.gnome.org in favor of  gitlab.gnome.org.
As part of that, we are mass-closing older open tickets in bugzilla.gnome.org
which have not seen updates for a longer time (resources are unfortunately
quite limited so not every ticket can get handled).

If you can still reproduce the situation described in this ticket in a recent
and supported software version, then please follow
  https://wiki.gnome.org/GettingInTouch/BugReportingGuidelines
and create a new ticket at
  https://gitlab.gnome.org/GNOME/gnome-devel-docs/-/issues/

Thank you for your understanding and your help.