976581 - Default button in OS X alerts lack focus

Status: NEW

(Toolkit :: Content Prompts, defect)

Description

[J. Daniel Ashton]

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_9_1) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/33.0.1750.117 Safari/537.36

Steps to reproduce:

Reading e-mails in a local folder, using Space or "n" to read the next message, until no more messages unread. Pressed Space again, got DoorHanger stating "Confirm Advance to next unread message in <myfolder>?" with No and Yes buttons. Yes button appeared to have keyboard focus.


Actual results:

Pressing Space did not click the Yes button.


Expected results:

Pressing Space should have clicked the Yes button.

Comment 1

[:aceman]

Do we have doorhangers for this dialog now? Or only on Mac?

Comment 2

[Josiah Bruner [:jsbruner]]

Not a doorhanger, but a dropdown dialog. The thing that needs to happen here is that the "yes" button needs focus, right now it is set as the default option, but without actual focus.

Comment 3

[:aceman]

On Win XP, the Yes button is displayed as the default (thicker border) and pressing Space activates it and the action proceeds. So is this a bug only in the implementation of the OS X "dropdown dialog" widget?

Comment 4

[Josiah Bruner [:jsbruner]]

Probably. I'll take a look at it.

Comment 5

[:aceman]

The code seems to be here, http://mxr.mozilla.org/comm-central/source/mail/base/content/msgViewNavigation.js#156 :
156         let promptText = document.getElementById("bundle_messenger")
157                                  .getFormattedString("advanceNextPrompt",
158                                                      [folder.name], 1);
159         if (Services.prompt.confirmEx(window, null, promptText,
160                                       Services.prompt.STD_YES_NO_BUTTONS,
161                                       null, null, null, null, {}))

const unsigned long STD_YES_NO_BUTTONS         = (BUTTON_TITLE_YES * BUTTON_POS_0) +
                                                 (BUTTON_TITLE_NO  * BUTTON_POS_1);

So this should make button 0 (yes) the default automatically.

Comment 6

[Josiah Bruner [:jsbruner]]

It is the default, but OS X dropdowns require focus to make using <space> work. That's what needs to be done.

Comment 7

[Josiah Bruner [:jsbruner]]

So it actually looks like this is a toolkit thing, so un-assigning myself. I tried doing this in JS (On the TB side), but the method is just way to hacky. We're going to need to extend confirmEx in toolkit.

Comment 8

[Neil Deakin]

Attachment: focusonprompts

This is because of bug 613760. I don't fix tab-prompts here but top-level modal prompts already do the right thing with focus in dialog.xml, so the call to setDefaultFocus should be skipped. I added a test for when Full Keyboard Access is on versus off.

Comment 9

[Justin Dolske [:Dolske]]

What exactly is the bug here? I'm a bit confused.

I'm not sure I agree with comment 0. At least, we're currently compatible with what Safari and Chrome do with confirm() -- there is a default button, but it's not focused, and so pressing space does nothing (but Enter triggers the default button). Our tab-modal and window-modal prompts appear to be consistent with each other.

I've always found this to be a little odd. But, well, that's OS X convention. I'd be open to changing the behavior of the tab-modal prompt, since the intent is sorta that it's prompt-of-the-web, and not a native OS prompt. (IIRC we didn't do this originally just to make the then-new tab-modal prompts not too different from the UI people were used to? It was a long time ago, my memory's fuzzy.)

Comment 10

[Justin Dolske [:Dolske]]

Is this bug only relevant with FKA enabled?

Comment 11

[Josiah Bruner [:jsbruner]]

It's possible we don't need to do this for *all* dialogs by default, as not all OS X dialogs do this, but we do need a way to do it if required. (Many Thunderbird dialogs require such behavior, but there is currently no elegant solution to accomplish this from the JS side)

I personally don't think it's bad to change the behavior across all dialogs, as most users don't gain or lose anything, but that's not up to me to decide. However, we (Thunderbird) do need a way to focus the default button through either a new default, argument, or method in order to optimize normal workflow UX.

Comment 12

[Neil Deakin]

(In reply to Justin Dolske [:Dolske] from comment #10)
> Is this bug only relevant with FKA enabled?

Yes. When it is enabled, a button would be focused in an alert or confirm type box.

In Chrome, type 'javascript:confirm('test') into the url field, and the Cancel is focused. In Firefox, do the same in a console, and the description is focused (although not visibly so). The cancel button should be focused.

Comment 13

[Justin Dolske [:Dolske]]

Comment on attachment 8383723 [details] [diff] [review]
focusonprompts

Review of attachment 8383723 [details] [diff] [review]:
-----------------------------------------------------------------

Ok. I think we probably shouldn't make the tab-modal prompt behave differently with FKA (so no followup to "fix" tab-modal prompts), though as I noted in my previous comment it's debatable if tab-modal should even do anything OSX-specific (ie, if we remove the OSXisms, FKA behavior becomes irrelevant).

Comment 14

[Matthew N. [:MattN]]

Bulk move to Toolkit::Notifications and Alerts

Filter on notifications-and-alerts-component.

Comment 15

[Neil Deakin]

I think this patch didn't work quite correct, and I don't remember. I'm not working on this now.