Closed Bug 1445482 (focus-visible) Opened 6 years ago Closed 3 years ago

implement :focus-visible pseudo-class (rename/alias :-moz-focusring)


(Core :: CSS Parsing and Computation, enhancement, P1)




85 Branch
Tracking Status
firefox61 --- wontfix
firefox85 --- fixed


(Reporter: dbaron, Assigned: emilio)


(Blocks 2 open bugs, )


(4 keywords, Whiteboard: [layout:backlog])


(1 file)

We should implement the :focus-visible pseudo-class in selectors4.  Chrome is implementing it; see bug 1442081 for the web-platform-tests they wrote.

We already implement essentially this as :-moz-focusring; we probably just need to rename and add a temporary alias, although there might be some other things that need to or should change for spec conformance.  (That said, the spec is pretty liberal, so we're likely OK.)
The recent discussion in suggests it might be a little more interesting than that.
[Triage 2018/03/23 - P3]
Priority: -- → P3
Keywords: site-compat
Mass bug change to replace various 'parity' whiteboard flags with the new canonical keywords. (See bug 1443764 comment 13.)
Keywords: parity-chrome
Whiteboard: [parity-blink]
There were some reasonably substantive changes to the spec for :focus-visible made in .

(Also, see asking for this feature.)
There's some interest for using :focus-visible for DevTools UI code. We have the usual issues with :focus styles applying on clicks and puzzling users, and I suggested :-moz-focusring as a possible fix, but some DevTools components can be used in other browsers (debugger-html and perf-html), so a standard solution would be better.
I'm trying out :-moz-focusring for devtools, but in Firefox 62 and 65 (Nightly) it seems to behave exactly like :focus.

Test case:

Tested on Linux:
- Firefox: With no keyboard interaction on the page, when clicking buttons and links, :-moz-focusring styles apply
- Chrome with Experimental Web Platform Features enabled in flags: buttons and links do not get or retain :focus-visible styles

Hey Florens, I worked on the Chrome implementation of :focus-visible with Alice Boxhall.

Is the behavior in Chrome's implementation what you'd want/expect?

Our thinking on the Chrome side has been that the semantics of the action should define whether or not a focus ring gets displayed (and if :focus-visible will match). Our general rule of thumb has been that if you were to click on a control on mobile, would it display a virtual keyboard? If "yes" then :focus-visible should match, regardless of the input modality (mouse, keyboard, pointer, etc). If the answer is "no" then :focus-visible will not match for mouse/touch/pointer, but it would match for keyboard focus.

So if you mouse click on an input, it will always match :focus-visible.
Whereas if you mouse click on a button, it will not match :focus-visible.

Hi Rob. In my tests the behavior in Chrome matched my expectations (but to be clear I only tested on desktop + mouse and desktop + keyboard).

One issue I had was that :focus-visible was in practice the same as :focus for text inputs. I understand the rationale, but it made it harder to pass design review with a fully accessible design. I could not provide a "subtle" :focus style and a more visible :focus-visible style like this:

input[type="text"] {
  border: solid 1px #bbb;

input[type="text"]:focus {
  border-color: rgba(100, 100, 255);

input[type="text"]:focus-visible {
  border-color: blue;
  box-shadow: inset 0 0 0 1px blue,
    0 0 0 3px rgba(100, 100, 255, 0.5);

In design review I was asked to only keep the 1px border color change for the majority use case of users clicking the text input, which rules out using :focus-visible there with Chrome's implementation.

I can probably live with that though. In other projects having strongly visible focus styles on text inputs was not an issue.

I tried to use :-moz-focusring for perf-html too, and I found that the behavior isn't what I expect from :focus-visible. As Florens said I couldn't find a difference between :-moz-focusring and :focus.

Chrome implementation makes sense, except I agree with Florens about the behavior for <input text> though: probably this would give more flexibility to web developers by implementing it the same way as for <button>.

See Also: → 1545499
Whiteboard: [layout:backlog]
Keywords: access
Blocks: unprefix

So here's a current description of what :-moz-focusring is doing:

  • If browser.display.show_focus_rings=true (Windows and Linux), then it's the same as :focus, effectively.
  • If it's false, then once you tab navigate, it becomes "true" for that document.

So it seems :focus-visible should be somewhat different to :-moz-focusring. In particular it should not be stateful.

Alias: focus-visible
Depends on: 1617600
Depends on: 1617608
Whiteboard: [layout:backlog] → [layout:backlog:2020q1]
Depends on: 1618639
Whiteboard: [layout:backlog:2020q1] → [layout:backlog:78]
Depends on: 1638127

Now that we triage by severity, setting priority to P1 to reflect backlog prioritization on this bug as either in-progress, or planned development in the near term. See

Priority: P3 → P1

Emilio's been working on this, so marking as ASSIGNED.

Assignee: nobody → emilio
Whiteboard: [layout:backlog:78] → [layout:backlog]

It has been enabled in Chrome 86 without a flag:

I see that example on in Firefox 81 Nightly almost works (it matches focus-visible on keyboard focus), without a flag as well.
Does it mean we can expect it in 81 with some fixes which will align it with the chrome behavior?

Hi! The :focus-visible experimental flag doesn't seem to work as intended in Firefox 84.0. :focus-visible styling is activated whenever an element is focused, even by a click event. (As Pavel noted, without the experimental flag enabled, the default :focus styling is applied on both keyboard and click focus.) I tested both ways on Mozilla's documentation of the pseudo-class.

Emilio, is this still on your radar? Is this behavior expected at this point, and is there any roadmap for a release of :focus-visible with updated behavior and without a flag?

Apologies if these sorts of questions don't adhere to Bugzilla Etiquette, by the way! I reviewed the guidelines and think it's ok, but I'm new here :)

Flags: needinfo?(emilio)

Can you elaborate, does :focus-visible incorrectly apply? Do you have a test-case? Or does the browser use focus rings? The browser uses :-moz-focusring for the time being, and unifying them is basically the precondition to ship this I suspect.

Flags: needinfo?(emilio)

Yes, with :focus-visible enabled in my Firefox config, clicking on the button and input field labeled "focus visible only" here applies the orange dotted focus ring. When clicking on the same button and field in Chrome, which implemented :focus-visible by default in v86, the orange focus ring does not appear; it's only applied when the user navigates to these elements using their keyboard, which is the expected behavior.

I cannot reproduce that, what OS are you on? And, can you file a separate bug about it instead?

Oh, or it may be that you have navigated by keyboard before. Firefox enables focus outlines on all elements once you've done keyboard navigation (but not before).

Firefox enables focus outlines on all elements once you've done keyboard navigation (but not before).

IMHO this is bound to create countless bug reports by clients and QA (similar to the report by Cara Price in this thread), and endangers :focus-visible as a viable solution.

I think the JavaScript focus-visible polyfill uses a more fine-grained approach, which avoids this pitfall?

Depends on: 1677376

(In reply to Florens Verschelde :fvsch from comment #20)

I think the JavaScript focus-visible polyfill uses a more fine-grained approach, which avoids this pitfall?

Well, it's not a pitfall, IMO, it's how various OSes have behaved historically. But anyhow I filed bug 1677376 to give this a shot.

Intent email, hopefully with a nice executive summary:

Pushed by
Enable :focus-visible on all channels for Firefox 85. r=edgar
Closed: 3 years ago
Resolution: --- → FIXED
Target Milestone: --- → 85 Branch

I have updated BCD for this feature and added a release note for Firefox 85.

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