1817634 - :focus-visible pseudo-class incorrectly enabled on mouse click when access keys are enabled

Status: VERIFIED FIXED

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

Description

[davri]

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:109.0) Gecko/20100101 Firefox/110.0

Steps to reproduce:

Enable the "Underline access keys when available" option in windows 10 Ease of access settings, and click on a link or a form element on a website that doesn't override the default ua styles (eg. developer.mozilla.org).

Actual results:

A double focus ring appears even when keyboard navigation isn't used. This wasn't the case in v109 and earlier versions.

Expected results:

Underlining access keys shouldn't have an effect on how mouse clicks are interpreted. Alternatively there should be an option to completely toggle the behavior (accessibility.mouse_focuses_formcontrol doesn't include dropdowns and clickable links).

Comment 1

[Emilio Cobos Álvarez (:emilio)]

This seemed like the intention of this code always, see bug 1807687 and the comments in the patch in particular. Seemed to be the Win32 behavior since ~forever. Creating a ui.showKeyboardCues preference in about:config with the value 0 overrides the system value. But maybe we should consider just removing that code and make it not force focus rings either.

Comment 2

[Emilio Cobos Álvarez (:emilio)]

Attachment: Bug 1817634 - Remove "show keyboard cues" handling. r=cmartin

Other browsers don't do this, and it might confuse users, see e.g., 1
and bug 1813684.

Before Firefox 110, we didn't do it consistently, but I fixed that in
bug 1807687. See comments in the patch for context, 2 in particular:

The code being removed here is intended to implement the Windows
setting 'Underline access keys' in the Keyboard Accessibility
control panel, which somewhat confusingly also controls whether
focus rings appear by default when clicking on controls. The former
part -- the showing and hiding of the underlines based on the
setting -- was never yet implemented, this is bug 25894. The focus
rings part was implemented.

Given:

• This setting is confusing.
• Modern windows apps and other browsers don't follow it.
• We already provide other means of achieving the same behavior
  (browser.display.show_focus_rings=true).

It seems better to remove. I asked Neil in bug 1813684 in case he felt
more strongly about this, and didn't hear back.

Comment 3

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

Set release status flags based on info from the regressing bug 1807687

Comment 4

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/726d4222d7f4
Remove "show keyboard cues" handling. r=cmartin

Comment 5

[Iulian Moraru]

https://hg.mozilla.org/mozilla-central/rev/726d4222d7f4

Comment 6

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

The patch landed in nightly and beta is affected.
:emilio, is this bug important enough to require an uplift?

• If yes, please nominate the patch for beta approval.
• If no, please set status-firefox111 to wontfix.

For more information, please visit auto_nag documentation.

Comment 7

[Emilio Cobos Álvarez (:emilio)]

Comment on attachment 9318819 [details]
Bug 1817634 - Remove "show keyboard cues" handling. r=cmartin

Beta/Release Uplift Approval Request

• User impact if declined: See comment 0 and links from the patch. This restores to pre-110 behavior for most users.
• Is this code covered by automated tests?: Yes
• Has the fix been verified in Nightly?: Yes
• Needs manual test from QE?: Yes
• If yes, steps to reproduce: comment 0
• List of other uplifts needed: none
• Risk to taking this patch: Low
• Why is the change risky/not risky? (and alternatives if risky): Trivial patch, removing code.
• String changes made/needed: none
• Is Android affected?: No

Comment 8

[Donal Meehan [:dmeehan]]

Comment on attachment 9318819 [details]
Bug 1817634 - Remove "show keyboard cues" handling. r=cmartin

Approved for 111.0b5

Comment 9

[Donal Meehan [:dmeehan]]

https://hg.mozilla.org/releases/mozilla-beta/rev/3a715c22b620

Comment 10

[Catalin Sasca, Desktop QA [:csasca]]

Reproduced the issue on Firefox 112.0a1 (2023-02-19) on Windows 10 by following the informations provided in Comment 0.

The issue is fixed on Firefox 111.0b6 and Firefox 112.0a1 (2023-02-26) on the same system.