Closed Bug 1765083 Opened 5 months ago Closed 3 months ago

Focus Ring not always shown when focus is set in Javascript

Categories

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

Firefox 99
defect

Tracking

()

VERIFIED FIXED
104 Branch
Tracking Status
firefox104 --- verified
firefox105 --- verified

People

(Reporter: peter, Assigned: emilio)

References

Details

(Keywords: dev-doc-complete)

Attachments

(3 files)

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

Steps to reproduce:

Set focus to an editable element on a form via javascript.

Actual results:

The element focused does not get a focus ring unless it is an INPUT element of type TEXT or a TEXTAREA.

Expected results:

The element should get a focus ring so that the user can know what the target of their keyboard.
Javascript is often used to validate a form and to set focus on an element that does not meet validation. Especially on complex forms, it can be hard for the end-user to draw their attention to the element without the aid of a focus ring.
Bug 1764172 relates, but was closed as Invalid. I am resubmitting as I think the issuse was misunderstood as relating to non-editable elements gaining focus.

The Bugbug bot thinks this bug should belong to the 'Core::DOM: UI Events & Focus Handling' component, and is moving the bug to that component. Please correct in case you think the bot is wrong.

Component: Untriaged → DOM: UI Events & Focus Handling
Product: Firefox → Core

This is again, so far, intended behavior, and it also matches other browsers afaict (except for <select> where blink behaves inconsistently).

However, I think this use case makes sense, and we should have a way to achieve what you want.

I filed https://github.com/whatwg/html/issues/7830 to discuss extending FocusOptions to add a way to force focus rings on programmatic focus.

That should solve your use case, AFAICT, but feel free to comment if not, or add more details to the issue as needed.

Summary: Focus Ring not shown when focus is set in Javascript → Focus Ring not always shown when focus is set in Javascript

Thanks for reconsidering this issue. I don't know why a focus ring would be unwelcome other than when the element is selected with the mouse where the end-user will know which element will then respond to keyboard. In all other circumstances, whether guided by tab-index sequence or code, the end user is never 100% sure which element will respond in the absence of a focus ring.
I also lack knowledge as to how disability readers detect focus so can't comment on that angle.
The only other path I could suggest is to be consistent and NOT set focus ring on the INPUT TEXT and TEXTAREA elements when focused by code, and let the developers show focus via CSS.
I have raised this an an issue with Chrome and will see how they respond. Perhaps they will follow your lead.

(In reply to Peter Brand from comment #3)

Thanks for reconsidering this issue. I don't know why a focus ring would be unwelcome other than when the element is selected with the mouse where the end-user will know which element will then respond to keyboard. In all other circumstances, whether guided by tab-index sequence or code, the end user is never 100% sure which element will respond in the absence of a focus ring.

I think the reasoning for the current behavior is that it creates unwanted focus rings in cases where e.g. a button opens a dialog with a default action or so. The point of :focus-visible was to avoid authors disabling focus outlines globally using CSS so generally we need to be wary of showing unwanted focus rings. When moving focus via script we used to always show focus rings and we got multiple bug reports about that, for the record (happy to dig a bit the history on Tuesday :)).

The only other path I could suggest is to be consistent and NOT set focus ring on the INPUT TEXT and TEXTAREA elements when focused by code, and let the developers show focus via CSS.

I suspect that would be an unwelcome breaking change. Focus rings are usually always shown on stuff that requires keyboard input.

I have raised this an an issue with Chrome and will see how they respond. Perhaps they will follow your lead.

Can you link the chromium issue here or in the html spec issue? Thanks.

Severity: -- → S3
Status: UNCONFIRMED → NEW
Ever confirmed: true
Assignee: nobody → emilio
Status: NEW → ASSIGNED
Pushed by ealvarez@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/570b38756541
Introduce FocusOptions.focusVisible. r=smaug,pip-reviewers
Created web-platform-tests PR https://github.com/web-platform-tests/wpt/pull/34789 for changes under testing/web-platform/tests
Status: ASSIGNED → RESOLVED
Closed: 3 months ago
Resolution: --- → FIXED
Target Milestone: --- → 104 Branch
Upstream PR merged by moz-wptsync-bot
Keywords: dev-doc-needed
Flags: qe-verify+
Regressions: 1782185
Attached file focusTester.html

Hello,
I managed to reproduce this issue on Firefox 103.0(build ID: 20220718155818) on Windows 10 64-bits using the attached testcase. Verified as fixed on Firefox 104.0b7(build ID: 20220807190148) and Nightly 105.0a1(build ID: 20220807214336) on Windows 10 64-bits, Ubuntu 22.04, macOS 12.

Status: RESOLVED → VERIFIED
Flags: qe-verify+ → in-qa-testsuite+

FF104 documentation work for this can be tracked in https://github.com/mdn/content/issues/19302 (complete).

You need to log in before you can comment on or make changes to this bug.