test(next): the accent is never orange and glass is never opaque

Merged
TE
15d ago
+593-0

Two standing rules become checks that fail. The accent rule runs two cases:

  • (a) The default theme, with the macOS accent forced to orange, shows no orange anywhere.
  • (b) Themes on schemas/theme/orange-accent-allowlist.json keep their own orange accent but still never show the system accent or opaque glass. Today that's Clay Orange (both its dark and light files). It's one named entry, allowed for now while coord-deputy confirms with Leo, so dropping it is a one-line change.

The gallery's theme input now carries a theme's own # cmux-accent, as ThemeBridge does in the app. Before this, the gallery dropped it.

The rules:

  • The accent is never orange. macOS draws its system accent, which is orange when someone picks orange in System Settings, anywhere a surface asks for it. Our surfaces never ask; every accent comes from the theme.
  • Glass is never opaque. A surface that blurs what's behind it and then paints a fill with alpha 1 hides the blur.

pane-toolbar found a menu highlighted in the system accent on 2026-10-20.

What the first full scan found, fixed here

The web scan covered 1529 of 1547 stages (the other 18 don't render in the gallery, on base too). It reported three things:

  • Opaque glass on .acpmux-composer-box, on nearly every agent-pane stage. On an opaque window the composer card is solid by design (Leo 10-14), but styles.css still blurred behind it with blur(18px). The blur now applies only to the see-through glass; it is off on an opaque window and under Reduce Transparency (composerStates.css).
  • outline: auto on the composer's context-breakdown popover. A popup takes focus when it opens, and the engine's ring is drawn in the macOS accent. popupSurface.css, which every host loads, now turns that ring off for every .ui-popup; their rows show the highlight.
  • A theme picker circle filled with AccentColor blue (false positive). ThemeBall paints a theme's own palette, and one theme's blue happened to match. The scan now skips [data-theme-ball].

The baseline stays empty.

Web: webviews/test/accent-glass-invariants.test.ts (browser lane, Chromium)

Renders every web gallery entry and variant in its component frame on the default theme. It scans the stage as it first paints, then twice more after Tab (focus rings are where the accent leaks most). Rules (test/support/accentGlassScan.ts):

  • system-accent: a computed color equal to a system color keyword that carries the OS accent (AccentColor, Highlight, SelectedItem, -webkit-focus-ring-color, -apple-system-control-accent), resolved in the engine. Text selection is included.
  • orange-accent: an accent-bearing color with an orange hue (OKLCH chroma ≥ 0.1, hue 35–78°). Accent-bearing means a visible outline, the caret, accent-color, ::selection, or the fill or border of a selected or highlighted row.
  • native-control-accent: a checkbox, radio, slider, progress bar or meter with accent-color: auto and its native appearance.
  • auto-focus-ring: outline: auto on the focused element.
  • opaque-glass: a backdrop-filter surface whose background alpha is 1. Reduce Transparency is never set, since solid is right there.

A browser can't be told to use an orange system accent, so the scan resolves the keywords instead. Known findings go in test/accent-glass-baseline.txt with their owner. A new finding fails the test, and a fixed one prints "drop it".

Native: CmuxNextDesignTests/SystemAccentOrangeTests.swift

Sets AppleAccentColor to orange in the process's argument domain, in memory only. It compares against systemOrange too, so the check holds even if AppKit keeps the host's accent. It checks the default theme's accent, accentFill, focusRing, menuHighlight and selectionFill, plus:

  • a themed menu's highlighted row (sampled),
  • a selected ThemedTableRowView (sampled, not emphasized),
  • a ThemedBezelButton's bezel,
  • the themed text fields' focus ring type.

Changelog

none

Observed / Not run

  • Web scan, in CI's react-apps-check:
    • On 414d0911 it found the three issues above in 1529 stages (about 330 s).
    • On 01cecb94 and c2d1b323, with the fixes, it passes with an empty baseline.
    • The test now also fails if it scans fewer than 90% of the stages or misses an allowlisted theme.
  • Native: SystemAccentOrangeTests passed all 6 tests on the fleet (cmux-ci run ... run-swift-testing-suites.sh, step 00d6a0b8b926400efdb6996c). It ran on a temporary merge of c2d1b323 with base, because base's CmuxNext tests did not compile until #23281 and #23386.
    • Each suite runs in its own process there.
    • That run's other failing suites are CmuxNextAppTests and AgentPane suites. This PR touches no Swift outside its own test file.
  • Reds this PR does not cause:
    • cmux-next fast tier: base's tests did not build until #23386.
    • The Chief first-turn token check, also red on #23281.
    • Agent-pane timing tests: composer grow-and-shrink (fixed on base by #23356), the harness-health notice layout shift, and the WebKit queued-prompt jitter.
  • Fixed here: the new rule in check-browser-test-lanes against opening every gallery entry. This test scans every entry, so it says why in a comment.
  • Review: an independent review subagent passed it. Its nits are fixed: the vacuous-pass guard, the scopes held for the whole test, and the accent setting restored after the suite.

No capture: the composer change only removes a blur behind a card that is already opaque, so nothing shows through it either way, and the popup change removes a focus ring the popups never meant to draw. Both are covered by the scan, not by pixels.

Agent session: cosmic-gray

🤖 Generated with Claude Code