1311444 - Text input with author styles (e.g. border) lacks focus indicator (non-natively styled inputs don't have outline by default)

Status: RESOLVED FIXED

(Core :: Layout: Form Controls, defect, P2)

Description

[Florens Verschelde :fvsch]

With this markup:

    <input type="text">
    <input type="text" style="border-width:1px">

Steps to reproduce:
1. Focus the first, then the second input element.

Expected result:
Both elements should show a visible indication of the focus state.

Actual result:
The second element shows no focus ring.

More complete test case:
https://jsbin.com/yopofej/edit?html,output

As other browsers do, when defining one of `border-*` and `background-*` properties, Firefox switches from a platform-specific rendering to a "plain input" style.

But unlike Chrome and Safari, this also kills the focus styles (which are indeed platform-specific in Firefox). This is an accessibility issue because authors will rarely redefine focus styles, while they will often define input styles that trigger "plain mode".

Opinion: Firefox should have a fallback focus ring style when in "plain mode", only removing this style when authors explicitly set the `outline` property.

What other browsers do (tested on Windows 10 and macOS):

- Chrome: blue focus ring on both inputs on both platforms
- Safari: light blue focus ring on both inputs
- Edge: blue border for first input, no style for second one (same as Firefox on Windows)

Comment 1

[Florens Verschelde :fvsch]

Similar issue for Edge:
https://developer.microsoft.com/en-us/microsoft-edge/platform/issues/9424720/

Comment 2

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

I somewhat suspect this is a recent-ish regression, although I'm not sure.  If so, it would be good to know when it regressed.

Comment 3

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

Attachment: reporter's testcase

Comment 4

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

OK, digging through the history of the code, it doesn't seem like a recent regression.

We'd need to implement a mechanism for having -moz-appearance suppressing outline, though.  The question, then, is whether that's the right thing to do for anything with -moz-appearance, or just some things.

Comment 5

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

(The most recent spec for 'appearance' that I can find is https://www.w3.org/TR/2004/CR-css3-ui-20040511/#appearance which is 12.5 years old and wasn't particularly well connected with reality even at the time.)

Comment 6

[Florens Verschelde :fvsch]

For the record, this are the UA styles reported by Chrome:

:focus {
  outline: -webkit-focus-ring-color auto 5px;
}
input:focus, textarea:focus, keygen:focus, select:focus {
  outline-offset: -2px;
}

BUT it's not actually the rendered style at all. I suspect that Chrome is using some shadow-ish thing to make their light-blue (#4d90fe), 2px slightly rounded outline.

So they have this default outline, and author styles can affect it. Testing each `outline-*` property individually:

- outline-color changes the UA's outline color, but it's still the UA's magic outline (which has 50% opacity).
- outline-style applies a standard CSS outline, with medium width, but it retains the #4d90fe color (while the spec says it should be either "invert" or "currentColor").
- outline-offset on its own is ignored.
- outline-width on its own is ignored.

Except for the rather specific treatment of `outline-color`, Chrome's "UA outline or author outline?" behavior for text inputs relies on the `outline-style` property. Authors can remove the outline altogether or define a different one (`outline:none;`, or funky things like `outline: solid 2px lime; outline-offset: 5px`).

An interesting approach for Firefox would be:
"If we're in platform-specific mode, use platform-specific focus styles (border, outline, box-shadow…). If not, and there are no author styles for outline-style, show a generic outline."

That would bring Firefox closer to Chrome (without the border-color subtlety), and provide authors a rather obvious ways to nullify this outline or redefine it if need be (which they probably already do for Chrome, if they are not happy with it).

Regarding `appearance`, I would keep the current behavior where `-moz-appearance: none` switches the text input in "plain" mode, but would still add the default focus ring on :focus (unless author styles define outline-style). Currently, `-moz-appearance: none` does not remove *all* styling, e.g. the input still has essential styles such as a border and a background and default text color; if we see the default focus ring as essential to accessibility, there is no rationale for removing it based on `-moz-appearance: none` only.

Comment 7

[Florens Verschelde :fvsch]

Another comparison point: what Firefox does for <button> elements.

With Firefox 51 on macOS:

- When the button as platform-specific styles, it has a thick light blue outline on focus.
- When the platform-specific styles are dropped (e.g. because of a `border-width:1px`), it shows ::moz-focus-inner on focus. (Related: bug 140562)

Comment 8

[Florens Verschelde :fvsch]

Is this bug missing anything to move from UNCONFIRMED to NEW?
And is there a relevant tag for accessibility-related bugs, maybe?

Comment 9

[Emilio Cobos Álvarez (:emilio)]

I think we should style these with outline-style: auto and we should suppress the outline-style: auto rendering when themed.

Comment 10

[James Teh [:Jamie]]

access-p1 because missing focus indicators.

Comment 12

[Emilio Cobos Álvarez (:emilio)]

Adding some keywords since I've spent far more time looking for this bug than what I'd like.

Comment 13

[Emilio Cobos Álvarez (:emilio)]

Attachment: Bug 1311444 - Disable some undesired outlines in the front-end. r=dao

These elements handle focus on their own. They're right now not
having outlines because they specify background-color, which disables
theming, but that is about to change.

Comment 14

[Emilio Cobos Álvarez (:emilio)]

Attachment: Bug 1311444 - Disable outline-style: auto rendering on themed widgets, and use it for elements for which we otherwise disable outlines by default. r=jamie

This guarantees outline indicators for these elements even if not
natively styled.

Depends on D73855

Comment 15

[Asa Dotzler [:asa]]

Updating the Accessibility Team's impact assessment to conform with the new triage guidelines. See https://wiki.mozilla.org/Accessibility/Triage for descriptions of these whiteboard flags.

Comment 16

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/40e959f28932
Disable some undesired outlines in the front-end. r=dao
https://hg.mozilla.org/integration/autoland/rev/0010e22f0daf
Disable outline-style: auto rendering on themed widgets, and use it for elements for which we otherwise disable outlines by default. r=Jamie,jfkthame

Comment 17

[Narcis Beleuzu [:NarcisB]]

https://hg.mozilla.org/mozilla-central/rev/40e959f28932
https://hg.mozilla.org/mozilla-central/rev/0010e22f0daf