63728 - Per-platform behavior of Enter key when a button is focused in a dialog

Status: VERIFIED FIXED

(Core :: DOM: UI Events & Focus Handling, defect, P3)

Description

[Jesse Ruderman]

(Noticed this while trying to figure out bug 63647, "Button should have focus 
by default in common dialogs")

In most Windows dialogs, a darker border around a button is used to indicate 
focus (along with a dotted border around the text inside the button).  In the 
Modern skin, the darker border means that a button is the default button.  In 
the Windows Classic skin, the dark border is used for both the default 
button /and/ the focused button.  In an Internet Explorer form, a darker border 
is also used for the default "submit" button, even if it doesn't have focus.

What's the correct time to draw dark borders around buttons in dialogs?  I like 
Modern's behavior the best, but it doesn't match what normal Windows programs 
do.  How do other operating systems and widget sets handle this?

(I'm using the Save/Don't Save/Cancel dialog in Mozilla Composer and other 
applications, but I assume that other dialogs are similar.)

Comment 1

[Matthew T (active 1999-2002)]

Now listen very carefully, this is a bit tricky.

The button which reacts to the Ctrl+Enter keyboard combo (and also the Enter 
key by itself, unless you happen to be in a multi-line text field) should have 
the special appearance. In Windows, the special appearance is a black border on 
the button. In Mac OS, the special appearance is a bit of gray piping around 
the button.

On Windows, if any control other than a button (like a text field, for 
instance) has focus, the default button (e.g. `Ok') is the one which takes the 
Ctrl+Enter combo, so it should have the black border. But if a button has 
focus, it steals the Ctrl+Enter event from the default button, so it 
temporarily steals the black border as well -- until focus is returned to a 
control other than a button.

On other platforms, I suggest you avoid this odd behavior. The default button 
should always take Ctrl+Enter (and Enter), and the focused control should 
always take Space. (On Mac OS, buttons traditionally haven't been able to take 
focus at all, so this problem doesn't arise.)

Comment 2

[Matthew T (active 1999-2002)]

So is this a Themes bug, or an XP Toolkit/Widgets bug? I don't know why it
should even be possible for different themes to have different behavior in this
regard -- the behavior should be platform-dependent, not theme-dependent.

Comment 3

[Blake Ross]

I'd say XPApps: GUI, because we'd probably be fixing this in the the bindings 
of some widgets, but it's not a toolkit thing.  I don't think Themes would be 
able to change the behavior of this, although they would be able to style it.  
I'll take a look at it sometime.

Comment 4

[Jesse Ruderman]

It seems to me that if a button has focus, pressing enter should activate that 
button (and not the default button).  Why would someone focus a button and then 
press enter expecting another button to be activated?

Comment 5

[Matthew T (active 1999-2002)]

Jesse -- If the default button appearance is more obviously different from the 
normal button appearance than it is on Windows (as it is on Mac OS, for 
example), the button which reacts to `Enter' should not change depending on 
which button is focused.

Meanwhile, I have found an exception to the rule I gave above. That is, Windows 
appears to have the distinction between `command' buttons and `block' buttons 
(bug 60355) which I previously thought was present only on Mac OS.

A `command' button, when it has focus, follows the behavior I gave above -- it 
can take the (Ctrl+)Enter key event (and therefore the dark border) away from 
the default button. But a `block' button cannot. For example, in the Display 
control panel, the `Cancel' and `Apply' buttons (when they have focus) can take 
the dark border away from the `Ok' button, but the `B' and `I' buttons cannot.

Comment 6

[Hixie (not reading bugmail)]

fyi what you are calling a "block" button is actually (internally) nothing more
than a checkbox with a different appearance. Don't shoot the messenger...

Comment 7

[timeless]

in windows they're called toolbuttons and yes they can be treated as 
checkboxes, or radio buttons, or push buttons.  In this case they are 
behaving like checkboxes.

Comment 8

[timeless]

oh and the other type of button is a command button.

Command buttons are things that you can activate w/ enter. toolbuttons aren't 
commands so they don't get enter.

Comment 9

[Jesse Ruderman]

See also bug 67923, "cancel button alert cannot be accessed via keyboard 
navigation".  Mozilla's current behavior (Enter always goes with the default 
button rather than the focused button) is confusing some people.

Comment 10

[Zach Lipton [:zach]]

Chaning the qa contact on these bugs to me. MPT will be moving to the 
owner of this component shortly. I would like to thank him for all his hard 
work as he moves roles in mozilla.org...Yada, Yada, Yada...

Comment 11

[Asa Dotzler [:asa]]

updating to new owner. sorry for the spam.

Comment 12

[Matthew T (active 1999-2002)]

*** Bug 71196 has been marked as a duplicate of this bug. ***

Comment 13

[Matthew T (active 1999-2002)]

From bug 71196, Boris has a partial patch at
<http://bugzilla.mozilla.org/showattachment.cgi?attach_id=30176>. Reassigning 
to Boris, and CCing Aaron so he knows what's going on.

Comment 14

[Charles Manske]

*** Bug 75578 has been marked as a duplicate of this bug. ***

Comment 15

[Boris Zbarsky [:bzbarsky]]

According to bug 71771, we trigger OK even when focus is on a textfield. :( 
should that be handled in this bug or elsewhere?

Comment 16

[Boris Zbarsky [:bzbarsky]]

Reassigning to component owner.  I have made no progress on this and I'll be
gone for the next few weeks....

Comment 17

[Jesse Ruderman]

*** Bug 86861 has been marked as a duplicate of this bug. ***

Comment 18

[Aaron Leventhal]

Reassigning alecf keyboard bugs.

-> ben, who also has dependency 71771

Comment 19

[Mike Kaply [:mkaply]]

Incidentally, this bug is really nasty on dialogs where the OK button 
is not enabled by default, like find or open file. The enter key 
simply doesn't work.

Comment 20

[Jesse Ruderman]

*** Bug 98808 has been marked as a duplicate of this bug. ***

Comment 21

[Jesse Ruderman]

See also bug 59840, enter key should activate default button on mac (the return 
key already works).

Comment 22

[augustz]

*** Bug 99440 has been marked as a duplicate of this bug. ***

Comment 23

[Boris Zbarsky [:bzbarsky]]

per hyatt's comments on bug 84602, over to hewitt (who is apparently doing
bindings for <dialog> and hence should just do this)

Comment 24

[Joe Hewitt (gone)]

I'm a bit confused by what this bug is about.  I fixed the problem of dialogs
firing the "ok" handler even when the ok button is disabled or has
default="true" removed (as was mentioned in this bug).  As far as the styling
problems, I'm not sure those are really things we want to fix.

If there are specific problems here, can somebody please clearly state exactly
what is supposed to be done here? If not, I'll close it out in a few days.

Comment 25

[Boris Zbarsky [:bzbarsky]]

Joe, the basic idea is this:

"Enter" should not always trigger the "ok" handler.  The behavior should be:

1)  On windows and OS/2, enter and control-enter trigger the currently focused
control if that control is a button.  Otherwise they should trigger the default
button (the "ok" handler, typically).  Space should trigger the focused control
if that focused control is a button.

2)  On other platforms, our behavior should be as it currently is -- enter
should trigger the default button and space should trigger the currently focused
control if that control is a button.

Does that help?

Comment 26

[augustz]

Exactly. Bug 99440, which I marked as a dupe of this was also gives a clearer 
description.

Comment 27

[Joe Hewitt (gone)]

fixed

Comment 28

[Akkana Peck]

Unix should do the same thing as Windows here, i.e. return should invoke the
currently focused buttons.  At least, that's what gtk and motif apps do, and I'm
forever getting the wrong thing because mozilla doesn't do the expected thing. 
Reopening so Unix can get the fix too.

Comment 29

[Joe Hewitt (gone)]

The code that does this is XP, it should work the same on Unix as on windows...
unless there are some weird focus things happening here only on Unix.

Comment 30

[Akkana Peck]

The problem seems to be coming from
xpfe/global/resources/content/unix/platformDialogOverlay.xul.  At the end of
that file, VK_ENTER and VK_RETURN are set to always call doOkButton(),
regardless of which button is focused.  If I remove those two lines, dialogs
work fine (I can focus any button and return will activate it).

Presumably removing the lines, as I did, is not the right answer (because then
return won't work when focus is in a text field or other non-button element in
the dialog).  Perhaps these lines should check whether focus is on one of the
other buttons before invoking doOkButton().

It looks like win/platformDialogOverlay.xul does the same thing as Unix.  I
don't have a windows machine handy to check; can you actually tab to a
non-default button and activate it with enter on windows?  If so, there must be
code somewhere that's behaving differently on windows vs. unix.

Comment 31

[Joe Hewitt (gone)]

akkana, this bug was referring to the new dialog implementation, using the
<dialog> tag.  The bug you are referring to is in the old dialog implementation,
using dialogOverlay.xul.  Blake is currently converting all dialogs to use
<dialog>, but in the mean time, you can verify that this works on Unix by
testing any of the dialogs currently using <dialog>, such as Find, Prefs, of
File Bookmark.

Comment 32

[sairuh (rarely reading bugmail)]

i tested this with the Prefs dialog... and came up with some interesting results.

builds tested:

linux - 2001.11.01.12 [rh6.2, stock gnome/sawmill]
winNT - 2001.10.31.03
mac 10.1 - 2001.10.31.13

case A: the 3 main buttons
------
when focus is on the OK, Cancel or Help buttons, hitting Enter will indeed
activate the focused button. for example, when Help is focused, hitting Enter
will launch the Help window. this works fine on linux, winNT and mac.


case B: Navigator panel, "Use Current Page"
------
1. tab over to focus the "Use Current Page" button.
2. hit Enter.

results:
noticed that the Location textfield briefly displays the url of the current page
--then the dialog is dismissed. open it up again at the same panel, and notice
that the Location field in the Navigator panel was *not* changed. this occurred
on linux, winnt and mac.

expected: the Location field should change to the currently displayed url, but
the dialog should *not* be dismissed.


case C: Navigator panel, "Choose File"
------
1. tab over to focus the "Choose File" button.
2. hit Enter.

results:

* on winNT, the native file picker briefly appeared, then both it and the Prefs
dialog were dismissed.

* on Mac, the native file picker appears, and the Prefs dialog persists.
however, i need to explicitly set focus in the file picker by clicking in it. is
that a known issue? moreover, after i select a file, the click Open, the Prefs
dialog is dismissed --and as with case B, the change was *not* made to Location.

* on linux, the xul file picker appears, but then the Prefs dialog goes away.
selection from the file picker is the same as on the mac --it's ignored.


case D: Cookies panel
------
1. tab over to focus the "View Stored Cookies" button.
2. hit Enter.

results:
* on winNT, Cookies dialog doesn't come up [if it did, it appeared too quickly
for me to see], and the Prefs dialog is dismissed.

*on linux and mac, the Cookies Mgr dialog appears, but then the Prefs dialog is
dismissed.

Comment 33

[Akkana Peck]

One case I hit a lot is dialogs from nsPromptService, e.g. quit when there's a
modified file in the editor or compose window gives you a "do you really want to
quit?" dialog, and this dialog doesn't follow the correct behavior.  I'd
appreciate a pointer to the correct bug to track that, if this isn't it.

Comment 34

[Joe Hewitt (gone)]

checked in a patch to prevent exiting the dialog when enter/return is pressed
while a button is focused

Comment 35

[sairuh (rarely reading bugmail)]

joe, thanks for fixing this! vrfy'd using the cases i described in my 2001-11-02
16:24 comments.

used the following commercial verif bits.

linux [rh6.2] - 2001.11.06.12
winNT - 2001.11.06.03
macOS 10.1 - 2001.11.06.08

Comment 36

[Akkana Peck]

Filed bug 108924 on the nsPrompt problem.

Comment 37

[sairuh (rarely reading bugmail)]

*** Bug 59840 has been marked as a duplicate of this bug. ***

Comment 38

[Matthew T (active 1999-2002)]

*** Bug 127892 has been marked as a duplicate of this bug. ***

Comment 39

[Matthew T (active 1999-2002)]

As noted in bug 127892, this bug wasn't fixed. Attachment 71520 [details] [diff] claims to fix 
the remaining problem, but it does not do the right thing on Mac OS X. On that 
platform, as I suggested in the last paragraph of comment 2, a button that is 
focused does *not* temporarily become the default button; it responds to Space, 
but Enter still triggers the OK or similar button.

Comment 40

[Joe Hewitt (gone)]

mpt, thanks for pointing out that this isn't fixed on OS X.  I'd prefer to open
a new bug which is just for the OS X problem, rather than re-opening a bug that
has been closed for 4 months.

Comment 41

[sairuh (rarely reading bugmail)]

vrfy'ing --remaining issues covered in bug 127892...and perhaps also bug 132720
(dups?).