Closed Bug 1708560 Opened 6 months ago Closed 6 months ago

Focus ring is broken at bottom of <input>

Categories

(Core :: Layout: Form Controls, defect)

Firefox 89
Desktop
Windows 10
defect

Tracking

()

RESOLVED WONTFIX
Tracking Status
firefox-esr78 --- unaffected
firefox88 --- disabled
firefox89 --- wontfix
firefox90 --- wontfix

People

(Reporter: alice0775, Unassigned)

References

(Regression, )

Details

(Keywords: nightly-community, regression)

Attachments

(5 files, 2 obsolete files)

Attached image image.png (obsolete) —

[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

Attached image image.png (obsolete) —

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
Attachment #9219381 - Attachment is obsolete: true
Attached image image.png
Attachment #9219378 - Attachment is obsolete: true

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.

Status: NEW → RESOLVED
Closed: 6 months ago
Resolution: --- → INVALID

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

This isn't INVALID. Should fix it!

Status: RESOLVED → REOPENED
Resolution: INVALID → ---

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.

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.

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

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

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

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.

Severity: -- → S4
Status: REOPENED → RESOLVED
Closed: 6 months ago6 months ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.