fix: keep the notch capsule inside the compact window

Merged
DA
2mo ago
+29-15

Summary

  • Fix: the compact notch capsule rendered nothing. The expanded panel is hidden with opacity: 0 alone, so it kept its full 620x520 layout box and focusable buttons inside a ~32px-tall window, leaving #root a scroll container (scrollHeight 496 vs clientHeight 32). On show, Chromium focused the first focusable element — the "Start microphone" button in the invisible panel — and scrolled it into view, pushing the compact stage to y: -428.5. The window was on screen and painting the whole time; only its content had been scrolled away. overflow: clip leaves no scroll container to move, and inert keeps focus out of a hidden stage.
  • Default change: --fixture only took effect during capture runs, so run.sh injecting --fixture smoke did nothing and the panel always showed live sessions — the opposite of what the docs said. The flag now works on its own, run.sh defaults to live sessions, and --fixture smoke is the opt-in.

Reviewed as two commits; the fix stands alone in ff3fc1d.

Evidence

  • Platform-independent checks: ./scripts/check.sh — passed (repository checks, Biome, typecheck, 36 tests, build)
  • macOS Electron verification (./scripts/verify.sh): not run locally — authored from a Linux workspace, so the macOS job in CI is the first full run. Behaviour was instead verified against a physical Mac over the DevTools protocol (below).

Measured on the live app, compact mode, before and after the fix:

before   rootScrollTop=428.5  activeElement=BUTTON.secondary-button  dotY=-416   visible=false
after    rootScrollTop=0      activeElement=BODY                     dotY=12.5   visible=true

Each guard was ablated independently to confirm what is load-bearing:

CONTROL (both guards removed)   scrollTop=428.5  dotY=-416   visible=false
overflow:clip ONLY (no inert)   scrollTop=0      dotY=12.5   visible=true
inert ONLY (overflow:hidden)    scrollTop=0      dotY=12.5   visible=true
both (shipped)                  scrollTop=0      dotY=12.5   visible=true

Either guard alone fixes the scroll. Both ship: overflow: clip is the structural
guarantee, and inert additionally stops a hidden button from holding keyboard
focus inside aria-hidden="true".

Both launch modes after the change:

./scripts/run.sh                  badge "LIVE"             indicator unknown    4 live sessions
./scripts/run.sh --fixture smoke  badge "FIXTURE · SMOKE"  indicator attention  3 fixture sessions

Automated visual evidence

Download the deterministic macOS evidence · workflow run

  • Commit: c2bc6580c10b12047cb8223482fefa100b6558b9
  • Scenario: smoke
  • Physical-notch check: not performed by CI

Physical-device evidence

  • Screenshot or screen recording: not attached — see note below
  • Physical-notch check: performed — capsule confirmed visible beside the notch on hardware after the fix, and confirmed absent before it
  • Device/display configuration: 16-inch MacBook Pro, macOS 26.3, 1728x1117 @2x, Dark Mode. AppKit reports safeAreaTop: 32, notchWidth: 185; notch spans x 771–956pt, and the indicator lands at x 974.5–981.5, 18.5pt clear of the housing.

Notes

  • The deterministic evidence PNGs cannot demonstrate this fix. Capture runs never call show(), so they never triggered the focus-driven scroll — the compact evidence screenshot looked correct throughout, before and after. Expect app-smoke-compact.png to be unchanged; it is not a regression signal here, and it is why the bug survived the existing visual-evidence gate. Worth considering whether a capture path that shows the window would be a useful follow-up.
  • Two adjacent behaviours were deliberately left alone to keep this focused: the muted unknown indicator colour (rgba(255,255,255,0.42)), now the common state since live is the default; and a second run.sh while one is running still silently quits and flips the running instance to expanded, hiding the capsule.

Open workspace in Conductor