chore(trace): split actions and context options into separate files

[Dmitry Gozman (dgozman)]

Summary

• before/after events move to trace.actions, the context options event moves to trace.meta, everything else stays in trace.trace.
• Trace loader now reads all files sharing the prefix: .meta first (it carries the trace version), then .actions, then .trace and the rest.
• Recorder creates .trace/.actions up front so a chunk that records nothing still produces valid entries.

[github-actions]

Test results for "tests 1"

1 failed
❌ [firefox-library] › library/browsercontext-storage-state.spec.ts:453 › should work when service worker is intefering and the origin is not open @firefox-ubuntu-22.04-node20

5 flaky

⚠️ [chromium-library] › library/browsercontext-page-event.spec.ts:173 › should work with Ctrl-clicking `@chromium-ubuntu-22.04-arm-node20`
⚠️ [firefox-library] › library/browsercontext-cookies-third-party.spec.ts:257 › third party 'Partitioned;' cookies `@firefox-ubuntu-22.04-node20`
⚠️ [firefox-library] › library/browsercontext-cookies-third-party.spec.ts:470 › top level 'Partitioned;' cookie and same origin iframe `@firefox-ubuntu-22.04-node20`
⚠️ [firefox-page] › page/page-event-request.spec.ts:181 › should return response body when Cross-Origin-Opener-Policy is set `@firefox-ubuntu-22.04-node20`
⚠️ [webkit-library] › library/browsertype-connect.spec.ts:813 › launchServer › should upload a folder `@webkit-ubuntu-22.04-node20`

51722 passed, 1247 skipped

---

Merge workflow run.

[github-actions]

Test results for "MCP"

2 failed
❌ [chrome] › mcp/webmcp.spec.ts:178 › browser_webmcp_call disambiguates duplicate tool names by frame @mcp-ubuntu-latest-chrome
❌ [firefox] › mcp/cli-save-as.spec.ts:26 › screenshot @mcp-windows-latest-firefox

8562 passed, 1446 skipped

---

Merge workflow run.

[github-actions]

🟢 None of the three failures are caused by this PR

Hi, I'm the Playwright bot and I took another look at CI after the latest push.

The MCP tracing failures I flagged earlier are gone — mcp/tracing.spec.ts now expects the .actions/.meta files. What's left is one test that is broken on main (browsercontext-storage-state.spec.ts:453, failing 49 of 49 runs in the results DB, including plain pushes to main) and two long-standing single-bot flakes. This PR only changes trace file layout; none of the three touch tracing.

Details

Overall: no failure is attributable to this PR. One is a pre-existing breakage on main, two are known flakes with failures on unrelated SHAs.

Pre-existing flake / infra

• [firefox-library] › library/browsercontext-storage-state.spec.ts:453 › should work when service worker is intefering and the origin is not open — not a flake, a pre-existing breakage: it has failed 49 of 49 runs across 17 distinct SHAs, on every Firefox bot (firefox-ubuntu-22.04-node20, firefox-windows-latest, firefox-macos-15-large/xlarge, tracing-firefox), including push runs on main (e.g. 500c9c82, 249916f0, 4dc79d4a, d4ce80d1 on 2026-09-14). Chromium and WebKit are green on the same test, so it's a Firefox-specific regression that predates this PR.
• [chrome] › mcp/webmcp.spec.ts:178 › browser_webmcp_call disambiguates duplicate tool names by frame — flaky: 2 of 152 runs failed for each of chrome and chromium, on unrelated SHAs — a main-branch push (d1ead3ec) and PRs feat(chromium): roll to r1245 #42683 / feat(mcp): add media emulation #42668. The webmcp call path doesn't read or write traces.
• [firefox] › mcp/cli-save-as.spec.ts:26 › screenshot <ref> — flaky and windows-firefox-only: 6 of 2103 runs failed, across 6 distinct SHAs (a main push ca667fee plus PRs fix(trace): keep client paths out of remote launch options #42436, feat(mcp): add browser_emulate_media tool and --color-scheme option #42244, test: race between disabling interception and network request in chromium #42254, fix(mcp): do not run heartbeat for clients without the event stream #42189). Green on chromium, chrome, msedge and webkit, all 2100+ runs each.

Reports triaged: tests 1 and MCP.

_{Triaged by the Playwright bot - agent run}

[github-actions]

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

🟢 None of the three failures look caused by this PR

One is already broken on main, the other two are known flakes that have failed on unrelated PRs. The diff is confined to trace file splitting, and the only shared helper it touches (serializedFS.ts) changes visibility only — private _flushFile → flushFile, no behaviour change. None of the three tests record or read a trace.

Details

Pre-existing failure (broken on main)

• [firefox-library] › library/browsercontext-storage-state.spec.ts:453 › should work when service worker is intefering and the origin is not open — this is red everywhere, not just here. In the aggregated CI results it has failed 25 of 25 runs, across 17 distinct head SHAs and 10 different PRs, including main pushes, first seen 2026-09-10 23:32 UTC — before this PR's head commit. The assertion is an unexpected extra cookie in the storage state:

  + Object { "name": "fromServiceWorker", "value": "yes" }
  

  That's service-worker cookie propagation, nothing the trace-file split reaches.

Pre-existing flake / infra

• [chrome] › mcp/webmcp.spec.ts:178 › browser_webmcp_call disambiguates duplicate tool names by frame — the test expects the "is registered in multiple frames, retry with the frame parameter" error but gets error: undefined, i.e. the second frame's tool registration hadn't landed when the call was made. A registration race, and it races elsewhere: in the chrome project the test has 52 runs, 0 final failures, 2 rescued by retry — one of those on unrelated feat(chromium): roll to r1245 #42683 (run 34655605068). Its two siblings in the same file were retry-rescued 4× and 2×. Worth noting honestly: this is the weakest of the three, since it had not finally failed before in this project — but it's flaked on a PR this one can't be responsible for, and the failure mode is timing, not tracing.

• [firefox] › mcp/cli-save-as.spec.ts:26 › screenshot <ref> — TypeError: Cannot read properties of undefined (reading 'name'). Out of 715 runs it has finally failed 3 times, all on unrelated PRs — #42189, #42254, #42244 — every one on mcp-windows-latest-firefox, the same bot that failed here. It was also retry-rescued on a plain main push (sha ca667fe). Same test, same bot, no involvement from this PR.

Reports triaged: tests 1 and MCP at sha 9f67ef5. The 5 flaky entries in the tests 1 report all passed on retry and aren't counted as failures.

_{Triaged by the Playwright bot - agent run}