WebKit pointer/focus lane: 6 real reds on first actual run — slash menu never mounts on WebKit; overlay focus-open broken on BOTH engines

[lalalune]

The WebKit cross-engine pointer/focus lane added for #10722 (opt-in webkit project in packages/app/playwright.ui-smoke.config.ts, PLAYWRIGHT_WEBKIT=1, Desktop Safari over the keyless chat pointer/focus/composer specs) was never actually executed anywhere — no workflow set the flag or installed the WebKit browser. Running it for real (locally, Playwright WebKit 1.61.1, stub stack) immediately surfaced real cross-engine divergences. Current tally after the first fix: 3 passed / 6 failed.

Fixed already (PR #11103): chat-overlay-controls-interactions "transcript text is selectable" — WebKit's getComputedStyle returns "" for unprefixed user-select (only -webkit-user-select reports); the spec now probes both and keeps the behavioral range-selection assert. The app itself is fine (Tailwind select-text emits both properties).

Remaining reds:

1. All four slash-commands.spec.ts tests (WebKit-only). composer.fill("/") never mounts slash-command-menu — the element is absent from the DOM entirely (screenshot shows the composer holding "/" with the app fully booted). Passes on Chromium. The menu mounts from useSlashMenu state (open = mode !== "none" && items.length > 0, items from useSlashCommandController's client.listCommands("gui") + filterCommandsForSurface). Since the transcript/stub API demonstrably works on WebKit in the same run, suspects are: the catalog fetch silently failing (.catch(() => []) swallows it — worth removing that silent default while debugging), filterCommandsForSurface gating on isAuthorized/isElevated state that hydrates differently, or a WebKit-specific difference in how fill() interacts with the draft-change plumbing. Needs runtime diagnosis with the catalog fetch observed.
2. conversation-management.spec.ts "message persists across a full page reload" (WebKit-only). Visibility timeout after reload — possibly WebKit page-lifecycle/bfcache interaction with the stub SSE stream.
3. chat-overlay-controls-interactions.spec.ts "long transcript scrolls" — NOT WebKit-specific. This fails on Chromium too, in isolation, at the current develop tip (ContinuousChatOverlay.tsx is byte-identical between develop and the PR branch): focusing chat-composer-textarea no longer flips the overlay to data-open="true". Whoever owns the overlay focus-to-open path should bisect this on develop — it looks like a real recent regression, hidden by CI's chronic queue.

CI wiring status: PR #11103 adds the lane to test.yml's zero-key browser job (installs WebKit, runs --project=webkit) as running-and-reporting (continue-on-error) so the reds above are visible on every PR without blocking unrelated work. Once 1-3 are fixed, flip the step to blocking by deleting continue-on-error — that's the whole remaining change.

Local repro: PLAYWRIGHT_WEBKIT=1 ELIZA_UI_SMOKE_FORCE_STUB=1 bun run --cwd packages/app test:e2e --project=webkit (needs bunx playwright install webkit).

[lalalune]

Resolved — full WebKit pointer/focus lane 3/9 → 9/9 (#11225, merged to develop).

• Finding Replace GPT-3.5 with Node Llama3 #3 (both engines, the live regression): focusing the composer no longer opened the overlay. Root cause was a boot-race in expand()'s reveal gate — on /chat the composer gains focus before the restored thread's messages arrive, so the one-shot focus→expand no-op'd and never fired once the thread loaded. Fixed by parking the open-intent and completing it on the reveal edge (only if the composer is still focused; the suppressExpandOnFocusRef contract is untouched). Reproduced on real Chromium ("long transcript scrolls": 16.5s timeout → 2.5s pass).
• Findings Integrate agent-twitter-client #1 & Replace OpenAI Whisper with Whisper Turbo #2 (WebKit-only): one root cause. The PROD renderer registers /sw.js, and WebKit — unlike Chromium — doesn't bypass a controlling service worker for page.route interception, so /api/* fetches went around the per-spec fixtures to the real stub (slash listCommands got the stub's empty catalog → menu never mounted; conversation reload rehydrated a foreign thread → timeout). Fixed with serviceWorkers: "block" on the webkit lane (parity with the existing desktop-webkit lane). Both specs stayed pristine.
• Also: the slash controller's .catch(() => []) that made this hard to diagnose now surfaces the error (+5 controller tests), and the sibling user-select assertion test(ui,app,agent): onboarding/voice/background/interaction QA follow-ups + de-larp (#11083 follow-up) #11103 missed now probes the -webkit- prefixed property.

Remaining (the issue's stated last step): flip the test.yml webkit step from continue-on-error to blocking. Recommend doing that once the lane has shown green on a real CI run of this merge (locally it's 9/9 + Chromium parity) — a one-line follow-up.