1765083 - Focus Ring not always shown when focus is set in Javascript

Status: VERIFIED FIXED

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

Description

[Peter Brand]

Attachment: Test page for various editable element types.

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.

Comment 1

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

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.

Comment 2

[Emilio Cobos Álvarez (:emilio)]

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.

Comment 3

[Peter Brand]

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.

Comment 4

[Emilio Cobos Álvarez (:emilio)]

(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.

Comment 5

[Peter Brand]

Chromium issues reported here - https://bugs.chromium.org/p/chromium/issues/detail?id=1317039

Comment 6

[Emilio Cobos Álvarez (:emilio)]

Attachment: Bug 1765083 - Introduce FocusOptions.focusVisible. r=smaug

As per:

• https://github.com/whatwg/html/issues/7830
• https://github.com/whatwg/html/pull/8087

Replace the internal preventFocusRing with the new flag.

Comment 7

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/570b38756541
Introduce FocusOptions.focusVisible. r=smaug,pip-reviewers

Comment 8

[Web Platform Test Sync Bot (Matrix: #interop:mozilla.org)]

Created web-platform-tests PR https://github.com/web-platform-tests/wpt/pull/34789 for changes under testing/web-platform/tests

Comment 9

[Atila Butkovits]

https://hg.mozilla.org/mozilla-central/rev/570b38756541

Comment 10

[Web Platform Test Sync Bot (Matrix: #interop:mozilla.org)]

Upstream PR merged by moz-wptsync-bot

Comment 11

[Ardelean Oana, Desktop QA [:oardelean]]

Attachment: 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.

Comment 12

[Hamish Willee]

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