feat(evaluate): opt in to Map and Set serialization

[Yury Semikhatsky (yury-s)]

• Add the JS-only serialize: ["Map", "Set"] option to evaluation APIs, with each type independently selectable and default behavior unchanged.
• Preserve Map and Set values for component mount and update, including callbacks inside collections.

[github-actions]

🟡 Two of the three MCP failures are known flakes; the dialog timeout is unproven

Hi, I'm the Playwright bot and I triaged the MCP run.

Nothing here points at the serialization change: the webmcp and cli-core failures both have a track record on unrelated SHAs. The dialogs timeout has no prior occurrence, so I can't call it either way.

Details

Pre-existing flake / infra

• [chromium] › mcp/webmcp.spec.ts:213 › browser_webmcp_call disambiguates same-name tools in identical same-origin frames — same test, same bot (mcp-macos-latest-*), same assertion (Found 2 WebMCP vs. 4) on feat(chromium): roll to r1245 #42683 (51a4b958), fix(test runner): forward the screen option from device descriptors #42681 (3ff52f2d) and a main push (6750decc) days before this PR. It fails roughly 1 in 44 runs, only on macOS.

• [firefox] › mcp/cli-core.spec.ts:131 › check — flips verdict independently of this PR: 8 failed of 717 runs, e.g. on feat(locator): page-free by locators resolved with page.get() #42157 (f7d67f59), with the snapshot missing [checked] [active]. Its neighbour uncheck flakes at the same rate. This PR touches neither the check flow nor snapshots.

Uncertain

• [chrome] › mcp/dialogs.spec.ts:263 › alert dialog w/ race — Test timeout of 30000ms exceeded. McpError: MCP error -32000: Connection closed. This is the test's only failure in 2136 runs, so I have no prior occurrence to point at. The signature is generic infra noise though — Connection closed shows up across 54 runs and 20 different MCP tests — and it was the single failure on that shard while the other 8561 MCP tests passed. The PR adds a serialization: 'extended' option that defaults to the old behaviour and doesn't touch dialog handling or the MCP transport, so a causal link isn't obvious. A rerun of that shard would settle it.

Separately, the trace-viewer.spec.ts failures in the "tests 1" report are real and caused by this PR — see the other comment.

_{Triaged by the Playwright bot - agent run}

[github-actions]

Test results for "MCP"

8564 passed, 1446 skipped

---

Merge workflow run.

[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

⚠️ [installation tests] › playwright-cli.spec.ts:21 › cli should work `@package-installations-macos-latest`
⚠️ [chromium-library] › library/video.spec.ts:736 › screencast › should work with video+trace `@chromium-ubuntu-22.04-node22`
⚠️ [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`

51760 passed, 1247 skipped

---

Merge workflow run.

[github-actions]

🟢 The one failure is pre-existing — it's broken on main, not by this PR

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

[firefox-library] › library/browsercontext-storage-state.spec.ts:453 › should work when service worker is intefering and the origin is not open fails in 39 of 39 runs in the aggregated CI results, including 22 push runs on main and a dozen unrelated PRs, all with the byte-identical error. Nothing here points at this PR.

Details

Overall: 1 failure, 5 flaky. The failure is a currently-broken test on main; the flakes are unrelated to the diff. Nothing in this PR's CI signal argues against it.

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 — broken at head, not by this PR. The test has never passed in the DB window: 39 runs, 39 failures, first seen 2026-09-14 15:44 UTC on a main push — before this PR's first CI run (19:04 UTC the same day). It fails identically on main (22 push runs) and on unrelated PRs feat(webkit): roll to r2362 #42736, feat(firefox): roll to r1546 #42735, fix(network): preserve dates in response headers #42734, test: evaluate() with falsy result #42728, test: fix click tests on android #42726, Fix spelling of restoring in credentials docs #42718, fix(server): end range responses when the file stream errors #42716, fix(reporter): do not hang perfetto writes after a stream error #42715, fix(trace-viewer): reject unsafe snapshot tag names #42712, chore(trace): split actions and context options into separate files #42654, always with the same diff:

  Error: expect(received).toEqual(expected) // deep equality
  - Expected  - 0
  + Received  + 4
    Array [ Object { "name": "foo", "value": "bar" }, + …
  

  Worth a note: this PR does touch packages/injected/src/storageScript.ts (extendedSerialization: true → serialize: ['Map', 'Set']), which is on the storage-state path, so it was the obvious suspect. But the failure predates the branch and reproduces without it, so the change isn't responsible. The extra cookies in the received array look like a cookie-collection regression from a separate commit.

• The 5 flaky results (playwright-cli.spec.ts:21, video.spec.ts:736, two browsercontext-cookies-third-party.spec.ts cases, page-event-request.spec.ts:181) all passed on retry and are in areas — CLI install, screencast, third-party cookies, COOP response bodies — that don't touch evaluation-argument serialization.

_{Triaged by the Playwright bot - agent run}