feat(trace-viewer): add "Display Aria" mode

[Pavel Feldman (pavelfeldman)]

Summary

• New "Display Aria" setting in the trace viewer renders the action screenshot and aria snapshot side by side instead of the DOM snapshot; hovering an aria node highlights its box on the screenshot.
• screenshot / aria-snapshot trace events are surfaced in the trace model; aria snapshots are captured with boxes, screenshots with css scale.
• The trace fixture option accepts snapshots: { dom, aria, screen }, same as tracing.start().
• --trace <mode> only forces the tracing mode, preserving other trace options from the config.

[github-actions]

Test results for "tests 1"

4 flaky

⚠️ [chromium-library] › library/chromium/chromium.spec.ts:213 › should intercept service worker requests (main and within) `@frozen-time-library-chromium-linux`
⚠️ [chromium-library] › library/video.spec.ts:664 › screencast › should capture full viewport `@chromium-ubuntu-22.04-arm-node20`
⚠️ [chromium-library] › library/tracing.spec.ts:493 › should produce screencast frames fit `@chromium-ubuntu-22.04-node24`
⚠️ [chromium-library] › library/video.spec.ts:736 › screencast › should work with video+trace `@chromium-ubuntu-22.04-node22`

51101 passed, 1209 skipped

---

Merge workflow run.

[github-actions]

Test results for "MCP"

1 failed
❌ [webkit] › mcp/network.spec.ts:210 › browser_network_requests lists a failed request once @mcp-macos-latest-webkit

8091 passed, 1294 skipped

---

Merge workflow run.

[github-actions]

🟡 One real failure — can't prove it either way

Hi, I'm the Playwright bot and I took a look at the CI failures here.

One genuine failure: [webkit] mcp/network.spec.ts:210 › browser_network_requests lists a failed request once. This PR is trace-viewer "Display Aria" work and touches no MCP or network code, so I don't see a path from the diff to it — but the exact test has never failed anywhere else in the results DB, so I can't call it a proven flake. Uncertain. The 4 "flaky" entries all passed on retry and are pre-existing; nothing to do there.

Details

Overall: The PR changes are confined to trace recording and the trace-viewer UI (tracing.ts, testTracing.ts, trace model, trace-viewer/src/ui/*, config). None of the changed files touch MCP or network-request handling, so the one hard failure is very unlikely to be caused by this PR — but I lack the cross-run evidence to close it as a flake.

Uncertain

• [webkit] mcp/network.spec.ts:210 › browser_network_requests lists a failed request once — fails on this branch (sha cbbad0f) with expect(received).toHaveLength(1) / received []: the failed request wasn't listed. Signature is a webkit-only capture-timing miss, which reads like a flake, and the diff doesn't reach the browser_network_requests tool. But across the results DB this test has 738 webkit runs with 0 hard failures and no prior flip on any unrelated SHA/PR — the only failure on record is this one. Without a same-test failure/flake somewhere the PR can't be responsible for, I can't prove it's a flake. A rerun of the MCP job would likely settle it.

Pre-existing flake / infra

• [chromium-library] library/chromium/chromium.spec.ts:213 › should intercept service worker requests (main and within) — flaky, passed on retry. 1 failure in 1027 chromium runs, rescued 216 times on unrelated SHAs.
• [chromium-library] library/video.spec.ts:664 › screencast › should capture full viewport — flaky, passed on retry. 1/798, rescued 271×.
• [chromium-library] library/tracing.spec.ts:493 › should produce screencast frames fit — flaky, passed on retry. 1/736, rescued 7×.
• [chromium-library] library/video.spec.ts:736 › screencast › should work with video+trace — flaky, passed on retry. 2/790, rescued 440×.

None of these exercise the trace-viewer aria path this PR adds.

_{Triaged by the Playwright bot - agent run}