1844715 - Tab navigation on many modal dialogs (including the "Restart Firefox" pop-up) can focus the window as a whole (no visible focus highlight)

Status: NEW

(Firefox :: Keyboard Navigation, defect)

Description

[buglinking]

Attachment: oneMoreTab.mov

[Affected versions]:

115.0.2 (64-bit)

[Affected Platforms]:

macOS 13.3.1 (22E261)

[Steps to reproduce]:

1. Open "about:preferences" page.
2. Search "History" in the "Find in Settings".
3. Click the "Never remember history" option under "History" section.
4. Press the "Tab" key to navigate on the "Restart Firefox" pop-up multiple times.

[Expected Results]:

• Two buttons ("Cancel" and "Restart Firefox now") are continuously alternately being focused.

[Actual Results]:

• On the third press of the Tab key, the highlight disappears, and no button is selected.

Comment 1

[BugBot [:suhaib / :marco/ :calixte]]

:buglinking, if you think that's a regression, could you try to find a regression range using for example mozregression?

Comment 2

[:Gijs (he/him)]

The window as a whole gets focused in this case. Focus is "continuous" because if you keep pressing tab, focus returns to the buttons, so I'm adjusting the summary.

IIRC being able to focus the document/window is an a11y requirement for dialogs like this. I don't know that there's anything that can be done about the styling. Either way, let's move this over to a11y as it's a generic problem, not specific to this particular dialog in the settings UI (e.g. if you use the "refresh Firefox/Nightly" button in about:support, the resulting dialog does the same thing).

Comment 3

[James Teh [:Jamie]]

Nope, the dialog (window) shouldn't be tabbable here. This doesn't seem to happen in all Firefox dialogs though; e.g. it doesn't happen in the Clear Recent History dialog.

In the refresh Firefox/Nightly dialog, it's actually the xul:description that's getting focus, not the window. The same is true for JavaScript alert() dialogs. I vaguely recall discussing this on another bug a while back, but I can't recall what happened with that in the end. I'll try to dig it up.

Comment 4

[James Teh [:Jamie]]

So we have bug1675992 which talks about removing tabindex="-1" from the body, which isn't quite what we're talking about here but is related. Curiously, bug 1675992 comment 1 says this was done due to XUL description elements being focusable and so we were trying to emulate that behaviour. I don't really understand that; there's still a XUL description element in JS alert() dialogs and it's still tabbable (not just focusable).

I think we should stop XUL description elements from being tabbable. I'm not sure if that's part of the widget itself or whether we just happen to give them a tabindex somewhere else.

Comment 5

[:Gijs (he/him)]

(In reply to James Teh [:Jamie] from comment #4)

So we have bug1675992 which talks about removing tabindex="-1" from the body, which isn't quite what we're talking about here but is related. Curiously, bug 1675992 comment 1 says this was done due to XUL description elements being focusable and so we were trying to emulate that behaviour. I don't really understand that; there's still a XUL description element in JS alert() dialogs and it's still tabbable (not just focusable).

I think we should stop XUL description elements from being tabbable. I'm not sure if that's part of the widget itself or whether we just happen to give them a tabindex somewhere else.

I agree it makes little sense, at an abstract level, to have tabbable/focusable description elements.

The alert dialog code forces focus on the description, here.

It's been like this since at least bug 613760, which added the explicit .focus() call but also claims that this was already the behaviour when these dialogs were still window-modal and separate (bug 613760 comment 16).

From memory, and from reading that bug diagonally, looks like it comes up there as well, I suspect one of the issues is that when the dialog appears we need focus to shift into the dialog, so that enter/esc do the right thing (accept/cancel the dialog). But unless "full keyboard access" is turned on, we can't focus these dialogs without something in it being focusable.

How is this supposed to be solved? Like, I don't see an obvious way other than having something in the dialog be focusable (even if it would not ordinarily be so). I'm not aware of a way we can move focus into the dialog without there being something to focus.

Comment 6

[James Teh [:Jamie]]

IMO, we should override full keyboard access being disabled in this case and focus the button regardless. Tabbing might not get a user back there, but that's their problem for having FKA disabled. :)

That said, I'm not sure how feasible this is from an implementation perspective...

Comment 7

[BugBot [:suhaib / :marco/ :calixte]]

The severity field is not set for this bug.
:dao, could you have a look please?

For more information, please visit BugBot documentation.

Comment 8

[Daniel Bodea [:danibodea]]

I can confirm this behavior on Windows 10 and Ubuntu 22. Mac OS 11 does not show ANY visual focus on keyboard navigation, in which case the severity is higher. Please NI me if a separate bug should be logged.