Bugzilla

Turning on the OS high-contrast setting leaves New Tab looking as it does normally while the surrounding chrome switches to high-contrast colors. Reported against the New Tab search bar, but it applies to New Tab's other surfaces too.

`browser/extensions/newtab/content-src/styles/nova/_tokens.scss` declares `:root.nova-tokens { ... }` outside any cascade layer, so it outranks every `@layer` in `tokens-shared.css` and `tokens-brand.css`, `tokens-prefers-contrast` included. It carries a `@media (forced-colors)` counterpart but no `@media (prefers-contrast)` one, so 35 of the 47 `prefers-contrast` token overrides never apply on New Tab -- among them `--border-color`, `--text-color`, `--toolbar-field-background-color`, `--toolbar-field-border-color`, `--toolbar-field-text-color`, `--button-border-color`, `--card-border-color` and `--icon-color`.

The platform split follows from where each signal lands. `prefers-contrast` tracks the OS setting in both the chrome and the content realm everywhere. `forced-colors` never applies to a chrome document, 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. So on Windows the shim's `forced-colors` block covers most of the gap; on Linux and macOS `prefers-contrast` is the only signal reaching the page, and the shim eats it.

Measured on `moz-urlbar` in about:newtab with `ui.useAccessibilityTheme=1`, against the address bar in the same window:

    token                             New Tab                        address bar
    --border-color                    light-dark(#B7B6BA, #949297)   CanvasText
    --toolbar-field-background-color  light-dark(#ffffff, #252428)   Field
    --toolbar-field-border-color      light-dark(#D6D5DA, #3F3E42)   CanvasText
    --text-color                      light-dark(#180E30, #F2F0F8)   CanvasText

Removing the `nova-tokens` class from the page's root element makes all four snap to the chrome values.

Four more are clobbered under `forced-colors` too, where the shim's base block sets them and its `forced-colors` block does not: `--panel-background-color` (`Canvas` where the shared sheet says `Menu`), `--panel-text-color`, `--text-color` and `--toolbarbutton-outline-color-selected`.

The file is generated by `mach buildtokens` from the `*.nova.tokens.json` inputs, so the fix belongs in the generator: emit the block inside a layer, or emit a `prefers-contrast` counterpart alongside the `forced-colors` one. Either way it changes how every New Tab surface renders under high contrast, not just the search bar.

Turning on the OS high-contrast setting leaves New Tab looking as it does normally while the surrounding chrome switches to high-contrast colors. Reported against the New Tab search bar, but it applies to New Tab's other surfaces too.

`browser/extensions/newtab/content-src/styles/nova/_tokens.scss` declares `:root.nova-tokens { … }` outside any cascade layer, so it outranks every `@layer` in `tokens-shared.css` and `tokens-brand.css`, `tokens-prefers-contrast` included. It carries a `@media (forced-colors)` counterpart but no `@media (prefers-contrast)` one.

The platform split follows from where each signal lands. `prefers-contrast` tracks the OS setting in both the chrome and the content realm everywhere. `forced-colors` never applies to a chrome document, 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. So on Windows the shim's `forced-colors` block covers most of the gap; on Linux and macOS `prefers-contrast` is the only signal reaching the page, and the shim eats it.

Measured on about:newtab with `ui.useAccessibilityTheme=1`, by removing the `nova-tokens` class from the page root and diffing the 47 tokens the toolkit sheets override under `prefers-contrast`:

- **Linux and macOS default** (`browser.display.document_color_use=1`, no forced colors): **31 of the 47 resolve to the wrong value.** A further 9 differ only in hex case and are the same color.
- **Windows default with OS HCM** (`document_color_use=0`, forced colors active as well): **14 resolve to the wrong value**, the rest being covered by the shim's `forced-colors` block or by Gecko's own forced-color adjustment.

A representative sample, New Tab against the address bar, under `prefers-contrast`:

    token                             New Tab                        address bar
    --border-color                    light-dark(#B7B6BA, #949297)   CanvasText
    --text-color                      light-dark(#180E30, #F2F0F8)   CanvasText
    --icon-color                      light-dark(#180E30, #F2F0F8)   CanvasText
    --background-color-canvas         light-dark(#F7F6FB, #131215)   Canvas
    --toolbar-field-background-color  light-dark(#ffffff, #252428)   Field
    --toolbar-field-border-color      light-dark(#D6D5DA, #3F3E42)   CanvasText
    --toolbar-field-text-color        light-dark(#3E315F, #E7E1F8)   FieldText

Under forced colors the wrong ones include `--panel-background-color` (`Canvas` where the shared sheet says `Menu`), `--panel-text-color` (a literal where it should be `MenuText`), `--toolbarbutton-outline-color-selected` (`ButtonText` for `SelectedItem`), the five `--icon-color*` tokens and `--text-color`.

The file is generated by `mach buildtokens` from the `*.nova.tokens.json` inputs, so the fix belongs in the generator: emit each block inside the cascade layer that matches it. Either way it changes how every New Tab surface renders under high contrast, not just the search bar.