Closed Bug 2069382 Opened 23 days ago Closed 22 days ago

Result rows in the New Tab search bar get a visible border in High Contrast Mode

Categories

(Firefox :: Address Bar, defect, P1)

defect

Tracking

()

RESOLVED FIXED
157 Branch
Accessibility Severity s4
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.

Keywords: access

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.

Assignee: nobody → dao+bmo
Status: NEW → ASSIGNED

(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 to Canvas, and border-color: Canvas matches it.

Ended up changing the approach here since the transparent border increasingly felt like a hack that seemed worth reconsidering.

The selected tip's background stops short of the row edges and leaves a gap above the tip's separator.

The selected tip's background spans the full row, flush with the tip's separator.

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.

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.

Seems pretty minor a11y wise

Accessibility Severity: --- → s4

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

Pushed by dgottwald@mozilla.com: https://github.com/mozilla-firefox/firefox/commit/aa5446f043a0 https://hg.mozilla.org/integration/autoland/rev/780c52f89cd1 Build the urlbar view row gutter out of padding rather than a transparent border. r=adw
Status: ASSIGNED → RESOLVED
Closed: 22 days ago
Resolution: --- → FIXED
Target Milestone: --- → 157 Branch
QA Whiteboard: [qa-triage-done-c158/b157]
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: