1708560 - Focus ring is broken at bottom of <input>

Status: RESOLVED WONTFIX

(Core :: Layout: Form Controls, defect)

Description

[Alice0775 White]

Attachment: image.png

[Tracking Requested - why for this release]: Visual glitch for INPUT tag

Steps To Reproduce:

1. Open data:text/html,<input type="text" /><br/><input type="text" /><br/><input type="text" /><br/><br/><input type="checkbox" id="checkbox"><br/><input type="checkbox" id="checkbox"><br/>
2. Move focus to input tab

Actual Results:
Focus ring is cut-off at bottom. Seems z-index problem of focus ring.

Expected Results
no glitch

Regression window:
https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=64bc9459015c77f3a032bc4dcb9465c44281b7d9&tochange=e2e3769604efd9724670ca1474377789e003a992

Comment 1

[Alice0775 White]

Attachment: image.png

The glitch also appear at right side.

1. Open data:text/html,<input type="text" /><input type="text" /><br/><br/><input type="checkbox" id="checkbox"><input type="checkbox" id="checkbox"><br/>
2. And focus

Comment 2

[Alice0775 White]

Attachment: image.png

Comment 3

[Emilio Cobos Álvarez (:emilio)]

This is how all outlines work, it's not specific to the non-native-theme, they're just covered by other adjacent elements because the non-native theme has a bigger outline.

Same happens in Safari for reference (though there inputs have margins by default so you need to remove that first). Adding margins by default would "fix" this test-case, but changing the default margin of the input is pretty risky for little benefit imo.

Comment 4

[Alice0775 White]

Attachment: Chromium92, Edge90 and Firefox88 Windows10

Hmm
At least, no glitch on Chromium92, Edge90 and Firefox88 Windows10.

Comment 5

[Alice0775 White]

This isn't INVALID. Should fix it!

Comment 6

[Daniel Holbert [:dholbert]]

As emilio said, this is indeed how outlines work.

Older Firefox versions do in fact render this same way, on MacOS at least. I'll attach a screenshot to demonstrate. And as Emilio said, Safari behaves this way as well.

Also: all browsers (including Chromium i.e. Chrome/Edge) agree that this is just how outline works; I'll post a testcase to demonstrate that.

The special thing that you're seeing in Chromium & Firefox-88-with-the-Win10-native-theme seems to be that these browsers are drawing their outline superimposed on the border, specifically for these form controls, which is a neat but kind of a quirky behavior from the perspective of how outline normally behaves. In Firefox's case, it looks like it's something we inherited from using Windows native widgets by default (which means we draw inputs and focused-inputs however Windows says to draw them, which has outlines superimposed over the same element's border). And in Chromium's case, they just seem to have a magic painting behavior for the default input focus-outline, where these outlines draw outside the border but always paint on top of any border that they overlap.

But if you explicitly specify an outline, browsers do all agree that focus-outlines get overlapped by subsequent content and subsequent contents' borders.

Anyway -- now that we aren't using Windows native widgets anymore, we don't have this outlines-draw-over-the-element's-own-border behavior that we were getting from drawing Windows's native behavior.

Comment 7

[Daniel Holbert [:dholbert]]

Attachment: screenshot of data URI testcase with Firefox 88 on macOS

Here's a screenshot of Firefox 88 in macOS, rendering your testcase from comment 0. This demonstrates that this behavior predates our switch to non-native themes, at least on macOS.

Comment 8

[Daniel Holbert [:dholbert]]

Attachment: screenshot of data URI testcase in Safari, after I've added `margin:0` to the inputs elements

And here's a screenshot of Safari, to show that this affects them as well if the input elements have 0 margin (which they don't by default; and we could hypothetically make this harder to hit by adding some margin like Safari does, but that's got some risk as Emilio noted).

Comment 9

[Daniel Holbert [:dholbert]]

Attachment: testcase with manually specified 'outline' for focused input

Here's a testcase with an explicitly-specified focus outline (absurdly-large, to make it large enough to definitely extend past the default margins in Safari).

All browsers agree that the focus outline gets covered up by the later content here.

As described above, the only reason this doesn't happen by default on Win10 is due to using native widgets (in Firefox 88) and due to some magic default behavior (in Chromium).

Comment 10

[Daniel Holbert [:dholbert]]

Hopefully the above comments/screenshots/testcase make it clearer why emilio closed this as INVALID & what's going on under the hood.

I do recognize that this is a papercut, though, and it manifests as a regression for certain content on Windows at least. It's possible we'll come up with a better solution in the future (or maybe we'll determine that we the risk/benefit calculus weighs in favor of adding some default margin like safari does; or something else that makes this go away). So, it's fine to have this reopened & track that hypothetical improvement. But I'm not sure there's anything we can do about it in the near term.