1881811 - The lack of a focus-ring in alert() dialog can cause users to inadvertently change tabs to Firefox View, if they press `Tab, Enter` to try to press the (not-visibly-focused) button

Status: NEW

(Toolkit :: Content Prompts, defect)

Description

[Daniel Holbert [:dholbert]]

STR:

1. View attached testcase.
2. When the alert appears: is the alert-dialog's button clearly focused? If not, press Tab and then Enter to attempt to focus and press it.

ACTUAL RESULTS:
The button is not clearly focused. When you press Tab/Enter, you end up switching tabs to Firefox View.

EXPECTED RESULTS:
Button should perhaps be styled as focused up-front, making it clear that you don't need to press Tab in order to focus it.
(And/or: perhaps the first Tab press should just make the focus-ring show up rather than changing focus?)

NOTES:
The button is actually already-focused when the dialog appears, but we just don't draw the focus ring.

When I press Tab in the STR, I'm actually inadvertently advancing focus off of the OK button, to the first focusable thing in our UI which happens to be the Firefox View icon in the toolbar.

It looks like we explicitly decided to hide the focus ring for cosmetic reasons in bug 1699259 , specifically here:
https://hg.mozilla.org/mozilla-central/rev/01e72f4f6021#l8.13
...which now lives here:
https://searchfox.org/mozilla-central/rev/f19d5bd57655b99f7cd8654674833890c09aed7d/toolkit/components/prompts/src/CommonDialog.sys.mjs#314

I wonder if we still think that focus-ring-hiding tradeoff is worth it? For comparison, Chrome on the same machine does show a focus-ring with my STR.

I noticed/filed this bug because I happened to trip this bug in the real world and get myself quite confused about why I'd moved to Firefox View. I was keyboard-only tabbing through the fields in an editable PDF. That PDF pops up an alert if you type gibberish into a date field (e.g. Date of Expiration). That happened for me, and I hit Tab/Enter to try to focus and press the OK button, since it wasn't already visibly focused.

Comment 1

[Daniel Holbert [:dholbert]]

Attachment: testcase 1

Comment 2

[Daniel Holbert [:dholbert]]

Attachment: screencast of this bug causing an unexpected tab-switch when filling out a PDF form

(In reply to Daniel Holbert [:dholbert] from comment #0)

I noticed/filed this bug because I happened to trip this bug in the real world and get myself quite confused about why I'd moved to Firefox View. I was keyboard-only tabbing through the fields in an editable PDF. That PDF pops up an alert if you type gibberish into a date field (e.g. Date of Expiration). That happened for me, and I hit Tab/Enter to try to focus and press the OK button, since it wasn't already visibly focused.

Here's a screencast to demonstrate this^, FWIW (with Firefox suddenly/unexpectedly changing tabs to Firefox View at the end of the screencast, causing user confusion & perhaps panic about their partially-filled-out-form being lost somewhere).

Comment 3

[Daniel Holbert [:dholbert]]

Attachment: screencast of expected-results in Chrome (focus ring shown, so it's clearer that you don't have to tab in order to focus the OK button)

Comment 4

[Daniel Holbert [:dholbert]]

Attachment: screenshot of Nightly, showing the (initially-hidden) focus ring

For reference, here's what the focus-ring looks like, when we do draw it (e.g. if you tab away and then back from the OK button).

In bug 1699259, Gijs was conveying an impression from Proton folks that the focus-ring felt too "heavy" and hence we needed to hide it. I wonder if that remains true in the current design & given the potential (minor-but-surprising) unexpected-Firefox-View-tabswitch footgun described here?

Comment 5

[Daniel Holbert [:dholbert]]

Attachment: screenshot of Chrome, showing the focus ring (up-front)

Here's Chrome's focus-ring, for comparison (looks pretty similar to ours, and they don't bother to suppress it up-front).

Comment 6

[Daniel Holbert [:dholbert]]

Attachment: Screenshot of Edge on Win11, showing an (inner) focus ring up-front

Comment 7

[Daniel Holbert [:dholbert]]

Safari 17.3.1 kind-of has a footgun here too, but in their case things are a bit different:
(a) Safari's alert OK button simpliy doesn't ever get any any focus-ring styling at all, no matter how hard I try to grant it tab-focus. (So they're not doing some sort of initial-suppression like we are)
(b) when you press Tab in the comment 0 STR in Safari, there's a much more substantial/in-your-face UI change (their awesomebar gets focused and it pops up its autocomplete-panel -- it's the next thing in the focus-order, for them). That's a much clearer signal that I'm not focusing the thing that I intended to focus, which makes me think twice before I press Enter. (In comparison, in Firefox, the Firefox-View focusring that appears when I press Tab is quite easy to miss, since it's small and at the very corner of your screen/peripheral vision.)

So this feels like a Firefox-specific issue at this point, I think.

Comment 8

[Daniel Holbert [:dholbert]]

Attachment: Screenshot of Nightly, with another dialog that does get the focus ring by default ("Confirm you want to leave")

I just noticed that in another dialog that looks similar to alert, we do show the focus ring by default -- the "confirm you want to leave" dialog that pops up, if you e.g. do a "close-tab" operation after typing some text into a field in an editable PDF.

This one's got two buttons, so the focus-ring is arguably more merited from a disambiguation perspective. But if we're comfortable with the "heaviness" of the ring here, it feels like we should be comfortable with it in the alert() popup as well...

Comment 9

[:Gijs (he/him)]

I can't reproduce the issue as filed on macOS. After [tab] the button is focused and [enter] closes the dialog, as expected.

Also, in your screencast, when you press [tab] the fxview tab is focused and has a focus ring...

Also, when testing Safari, did you enable OS "keyboard access to all controls" in the macOS system settings/preferences? Otherwise, buttons would simply never receive focus, and that would explain some of what you describe in comment 7.

An alternative solution here may be for tabbing into the dialog to focus-capture (ie it should then not be possible to use the tab keys to "tab out of" the dialog at all). Historically, this was not possible in HTML/DOM/Gecko. html:dialog I think now supports it; I don't know if it's possible to use inert similarly here, without breaking other things (e.g. we'd still want users to be able to use the mouse or keyboard shortcuts to close tabs that have content dialogs open, because some websites abuse such dialogs and we don't want to remove control from users).

I filed the original bug in response to UX requests. A change here would want input from UX, too.

Also, for future reference, you can just hit [esc] to close (really, cancel) a dialog like that, irrespective of what is focused.

(In reply to Daniel Holbert [:dholbert] from comment #8)

Created attachment 9382400 [details]
Screenshot of Nightly, with another dialog that does get the focus ring by default ("Confirm you want to leave")

I just noticed that in another dialog that looks similar to alert, we do show the focus ring by default -- the "confirm you want to leave" dialog that pops up, if you e.g. do a "close-tab" operation after typing some text into a field in an editable PDF.

Confusingly, I also cannot reproduce this. I don't see a focus rectangle by default for beforeunload dialogs (again, on macOS), until I start tabbing around. It's possible we do focus differently on macOS for alerts and that is causing the difference?

Either way it's really a UX question, not an engineering one.

Comment 10

[Daniel Holbert [:dholbert]]

Thanks for the reply!

(In reply to :Gijs (he/him) from comment #9)

I can't reproduce the issue as filed on macOS. After [tab] the button is focused and [enter] closes the dialog, as expected.

I should clarify that I'm testing Firefox on Ubuntu 22.04 so far.

But I can repro on macOS too -- I just tested Nightly on macOS and I'm seeing essentially the same results as I described/screencasted here. With the attached testcase, after the alert appears: if I press Tab, then focus moves to the fxview tab. At that point: Enter (or rather Return) has no effect on macOS, nor does Esc; but Space activates the fxview tab.

Also, in your screencast, when you press [tab] the fxview tab is focused and has a focus ring...

Right, and once the user has noticed this, things make a bit more sense. The issue is that this fxview focus-ring-appearing is quite easy to miss during the STR here, since the fxview tab is quite small and way off in the corner, which isn't the area of the screen that you're looking at when you're trying to dismiss the alert() dialog.

Also, when testing Safari, did you enable OS "keyboard access to all controls" in the macOS system settings/preferences? Otherwise, buttons would simply never receive focus, and that would explain some of what you describe in comment 7.

I did not activate that, no. I've now tried activating that setting (for me it seems to be called "Full keyboard access", and that still doesn't give me focus-rings around buttons or make things behave as I'd expect (in Safari or in Firefox [EDIT: after more testing with this setting, I do see some focus-rings on buttons in Firefox, e.g. in the beforeunload dialog, but the ring behaves a bit strangely; it seems like focus moves via a combination of arrowkey and Tab navigation]). Though macOS does start drawing blue boxes around parts of the screen that generally have focus (just, not at the granularity level of individual buttons).

Also, for future reference, you can just hit [esc] to close (really, cancel) a dialog like that, irrespective of what is focused.

Yup, I just happened to be in "form-filling mode" when I initially triggered this bug in the wild, so my muscle-memory was configured for tabbing-to-focus-the-form-field-that-I-want-to-activate. :) And the button in the alert dialog was not visibly focused, which is why I pressed Tab/enter to focus/activate it.

(Also, RE "irrespective of what is focused" -- actually, Esc doesn't dismiss the alert dialog, after you've pressed Tab once and transferred focus to the fxview button in the tabstrip. This sort of makes sense, though.)

I just noticed that in another dialog that looks similar to alert, we do show the focus ring by default [...]

Confusingly, I also cannot reproduce this. I don't see a focus rectangle by default for beforeunload dialogs (again, on macOS), until I start tabbing around. It's possible we do focus differently on macOS for alerts and that is causing the difference?

Yeah, on macOS, I can't reproduce focus rings on this beforeunload dialog, in the default system configuration. I think you're right; we must do button focusrings differently on macOS, in general, to align with platform conventions or something.

Either way it's really a UX question, not an engineering one.

Fair enough.

Comment 11

[Daniel Holbert [:dholbert]]

Regarding this being a UX-question: perhaps victoria is the right person to ask, or knows who to ask.

Quick recap: we made a call back in the Proton days to initially suppress the focus ring on the ok button in alert() dialogs (bug 1699259) on platforms where we show a focus ring on buttons (Windows and Linux), but this seems a bit inconsistent as compared to other dialogs (e.g. the beforeunload "confirm you want to leave" dialog) and can lead to user confusion/minor-footgunning as described here. Also, Chrome/Edge show focus rings (which look similar to ours) around their OK buttons in the alert dialog, which gives some credibility to this being a reasonable thing to do.

Would it be alright UX-wise to just show a focus ring around the OK button in alert() dialogs (on platforms where we show focus rings), like we do for e.g. the "confirm you want to leave" dialog?

Comment 12

[Daniel Holbert [:dholbert]]

Attachment: screencast comparing Nightly beahvior with alert() (no focusring around ok button until I explicitly tab away and back) vs. beforeunload (focusring shown up-front)

Comment 13

[Daniel Holbert [:dholbert]]

Comparing a bit more broadly to other similar-looking dialogs the Ctrl+Q confirmation dialog (if Confirm before quitting with Ctrl+Q is checked) does not initially show a focus-ring, nor does the "Clear browsing data and cookies" dialog. However: it's less of an issue for these ones, since these dialogs are modal for the whole window and the Tab-keypress form-field-navigation is scoped to the dialog itself, which makes it easier to see where focus is once you press Tab.

In contrast, for alert(): when you press Tab to find out where focus is, you might not notice that you've inadvertently established a focus ring around somewhere far away (to the button at the extreme top-left corner of your Firefox window).

Comment 14

[Victoria Wang [:victoria]]

Thanks Daniel - I’m going to forward this to the #acorn-design-system slack channel.

Comment 15

[Daniel Holbert [:dholbert]]

Per discussion in https://mozilla.slack.com/archives/CNP7Q51KN/p1709164170483509 , it seems UX is on board with fixing this, i.e. not-suppressing this particular focus ring on alert() dialogs.

Comment 16

[Daniel Holbert [:dholbert]]

(I suspect this is a trivial fix; ni=me to look into a patch here in the next few days, if nobody does it first.)

Comment 17

[:Gijs (he/him)]

bug 1704882 also looks relevant here, as there is code in SubDialog that explicitly suppresses focus rings, cf. https://searchfox.org/mozilla-central/rev/b73676a106c1655030bb876fd5e0a6825aee6044/toolkit/modules/SubDialog.sys.mjs#900 .

Comment 18

[:Gijs (he/him)]

Also, off-hand it looks like https://searchfox.org/mozilla-central/rev/b73676a106c1655030bb876fd5e0a6825aee6044/toolkit/modules/SubDialog.sys.mjs#716 is already attempting to do some kind of focus trapping? It would be useful to know if that's broken entirely in some way.