Result rows in the New Tab search bar get a visible border in High Contrast Mode
Categories
(Firefox :: Address Bar, defect, P1)
Tracking
()
| Tracking | Status | |
|---|---|---|
| firefox157 | --- | fixed |
People
(Reporter: dao, Assigned: dao)
References
Details
(Keywords: access, Whiteboard: [sng][mcab-hnt])
Attachments
(5 files)
Every row in the New Tab search bar's results view is drawn with a thick border in High Contrast Mode. The address bar's results view is not.
.urlbarView-row uses a transparent border as a spacer -- --urlbarView-row-border: var(--urlbarView-row-gutter) solid transparent in browser/themes/shared/urlbar/view-nova.css, with background-clip: padding-box, so the background pill is inset while the row keeps its full-height hit area. Gecko stopped honoring transparent for border-color under forced colors (bug 1740924), so the spacer reverts to currentColor and paints.
Only the New Tab bar is affected because a chrome document never forces colors. forced-colors is permanently none in browser.xhtml, and in content it follows browser.display.document_color_use, which defaults to 0 (mirror the OS setting) on Windows and 1 (off) on Linux and macOS.
Measured with ui.useAccessibilityTheme=1 and browser.display.document_color_use=0, light theme:
address bar row border 3px solid rgba(0, 0, 0, 0)
New Tab row border 3px solid rgb(0, 0, 0)
New Tab row, selected border 3px solid rgb(255, 255, 255)
Giving the border a system color under @media (forced-colors) fixes it: the surface behind the rows computes to Canvas, and border-color: Canvas matches it.
Updated•23 days ago
|
| Assignee | ||
Comment 1•23 days ago
|
||
A border width snaps to whole device pixels and padding does not, so rows grow by the difference: 1px in chrome and 1.5px in New Tab at a device pixel ratio of 1, and 0.5px in New Tab at 2, where chrome's gutter is already integral. Everything else holds across normal, compact and touch density and across plain, rich-search, tip and realtime rows, with two exceptions to check: a tip's background now spans the full row, flush with the tip's separator, and a realtime item's hit area is now its pill rather than the pill plus a gutter.
Updated•23 days ago
|
| Assignee | ||
Comment 2•23 days ago
|
||
(In reply to Dão Gottwald [:dao] from comment #0)
Giving the border a system color under
@media (forced-colors)fixes it: the surface behind the rows computes toCanvas, andborder-color: Canvasmatches it.
Ended up changing the approach here since the transparent border increasingly felt like a hack that seemed worth reconsidering.
| Assignee | ||
Comment 3•23 days ago
|
||
The selected tip's background stops short of the row edges and leaves a gap above the tip's separator.
| Assignee | ||
Comment 4•23 days ago
|
||
The selected tip's background spans the full row, flush with the tip's separator.
| Assignee | ||
Comment 5•23 days ago
|
||
Each item's border box outlined in red. The border box is the hit area, and it extends ~3px beyond the pill on every side (74px tall against a 68px pill), so adjacent outlines nearly touch.
| Assignee | ||
Comment 6•23 days ago
|
||
Each item's border box outlined in red. The hit area is now the pill itself (68px), and the items are spaced by the gap instead.
| Assignee | ||
Comment 8•22 days ago
•
|
||
(In reply to Eitan Isaacson [:eeejay] from comment #7)
Seems pretty minor a11y wise
I should have made clearer how this manifests for users. A screenshot of the problem is in bug 2069260 comment 0. I wouldn't say it's minor within the context of that search bar.
Seems like an S3 to me but I'll fix it either way.
Comment 10•22 days ago
|
||
| bugherder | ||
Updated•13 days ago
|
Description
•