(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.)

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.)

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.

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.

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?

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.

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...

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.

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.

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.

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...

updating to new owner. sorry for the spam.

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

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.

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

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

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

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

Reassigning alecf keyboard bugs. -> ben, who also has dependency 71771

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.

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

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

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

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

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.

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?

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

fixed

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.

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.

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.

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.

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.

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.

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

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

Filed bug 108924 on the nsPrompt problem.

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

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

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.

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.

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