Focus outline gets covered up in searchfield on https://bugs.chromium.org/p/chromium/issues/list
Categories
(Web Compatibility :: Desktop, defect)
Tracking
(Not tracked)
People
(Reporter: dholbert, Unassigned)
References
()
Details
(Keywords: webcompat:site-wait)
Attachments
(4 files)
STR:
- Be sure you have
widget.non-native-theme.enabled
set totrue
in about:config (I believe this is the default on Linux and Mac) - Visit https://bugs.chromium.org/p/chromium/issues/list
- Focus the search field at the top.
ACTUAL RESULTS:
The focus outline is missing on the right side of the textbox.
EXPECTED RESULTS:
No awkwardly-missing focus outline.
Firefox Nightly gives ACTUAL RESULTS.
Firefox Nightly with non-native theme disabled gives EXPECTED RESULTS (on Linux at least).
Chrome and Safari give EXPECTED RESULTS, basically (their focus outline is partly cropped, but not entirely, so the textbox is still fully contained in the outline). I think that might mean their focus outline has a little bit of "overdraw" into the inside of the widget, perhaps, and maybe that's the part that's showing up?
(This might just be an issue where the site just isn't considering focus outlines; we can morph it into a webcompat/outreach issue if needed.)
See attached testcase for a reduced version which reproduces the issue the same as the live site for me.
Comment 1•4 years ago
|
||
This is what I see with the native theme enabled. What do you see?
Chrome does add half a pixel into the box, but it only does so with outline-style: auto
and I think it is wrong.
In Safari the layout is broken because they have margins by default for <input>
and <button>
, if you remove them they render like us.
Comment 2•4 years ago
|
||
Reporter | ||
Comment 3•4 years ago
|
||
This is what I see with the native theme enabled. What do you see?
See attached screenshot.
I'm on Ubuntu 20.10; and I do have 200% pixel-scaling configured in my system settings, which might be involved as well. But yeah, if this didn't reliably work before non-native theme, then it's definitely less of a concern.
Reporter | ||
Comment 4•4 years ago
|
||
(In reply to Daniel Holbert [:dholbert] from comment #0)
Firefox Nightly with non-native theme disabled gives EXPECTED RESULTS (on Linux at least).
Correction/update: I only get expected results when I have 200% pixel-scaling in my system settings. If I change that to 100%, then I get "actual results" (no right border), with the native theme (i.e. the pref set to false
), as shown in Emilio's screenshot.
So yeah, it looks like our behavior has only changed here for folks with HiDPI monitors with e.g. 200% pixel scale.
Comment 5•4 years ago
|
||
I have a hidpi monitor fwiw. But the yaru theme might end up having slightly different outlines. Anyhow given this and the safari behavior I think this is mostly a site issue.
Reporter | ||
Comment 6•4 years ago
|
||
Sounds good; reclassifying as such. Thanks for taking a look.
Comment 7•4 years ago
|
||
Chrome does add half a pixel into the box, but it only does so with
outline-style: auto
and I think it is wrong.
Should there a bug on Chromium bug tracker? I can do it.
When I change the drop down to have we can see the outline.
/* Inline #301 | https://bugs.chromium.org/p/chromium/issues/list */
mr-dropdown {
margin-left: 2px;
}
ok let's report it to Google.
Reporter | ||
Comment 8•4 years ago
|
||
(In reply to Karl Dubost💡 :karlcow from comment #7)
Chrome does add half a pixel into the box, but it only does so with
outline-style: auto
and I think it is wrong.Should there a bug on Chromium bug tracker? I can do it.
I defer to emilio on this; but to me, this feels like some magic automatic default behavior, with no "correct" & hence perhaps not bugworthy.
When I change the drop down [...]
This styling doesn't quite work (or isn't quite complete), because it creates a visible gap in the broader widget's border. (You can see this gap more clearly if you use an even larger margin-left
value.)
My analysis/suggestion: the problem is really that the mr-dropdown
component looks transparent, but really it has a white background (background: var(--mr-search-bar-background);
) and that white background is what's stomping on the outline of the previous text-input widget.
So: I'd suggest that they make that component actually transparent (with e.g. background:none
), and specify the white background (if they even need to) at a higher level, maybe on the form
wrapper-element.
Comment 9•4 years ago
|
||
background: none
makes two gray bar visible for the dropdown on top of the outline, but probably better indeed. Well not ours to solve for their design choice. :)
Comment 10•4 years ago
|
||
Reported at https://bugs.chromium.org/p/monorail/issues/detail?id=9261
As we can't close as a DUPLICATE of another repo, I'm closing it as WONTFIX
Description
•