Caused by this PR

• [firefox-page] › page/firefox-network-response.spec.ts:50 (200 and 302), :80, :105 — the tests this PR adds. They assert separate header fields via headersArray(), but ffNetworkManager.ts now hands event.headers straight to network.Response with no splitting at all, so the combined Juggler values come through as single entries.

• [firefox-library] › library/har.spec.ts:233 › should include set-cookies and :277 › should include set-cookies with comma — both send multiple Set-Cookie fields and expect multiple parsed cookies in the HAR. With the split gone from the response path, HAR sees one Set-Cookie header whose value is name1=…\nname2=…\nname3=…, so only the first cookie parses.

• [firefox-page] › page/page-network-response.spec.ts:239 › should report multiple set-cookie headers — same cause: expects ['a=b', 'c=d'] from headersArray(), gets a single a=b\nc=d entry.

• [firefox-page] › page/page-network-response.spec.ts:203 › should report all headers — expects header-a as three separate entries. Juggler combines those with , , and the comma split that used to recover them is gone. This one is the intentional behaviour change the PR documents ("separate entries are not always available"), but the test was left untouched, so it now fails on Firefox.

The Set-Cookie cases look like an oversight rather than intent: calling splitSetCookieHeader() on event.headers in FFNetworkManager._onResponseReceived should restore them without bringing back the comma splitting. should report all headers needs a deliberate call — either a Firefox fixme/adjusted expectation, or the header is genuinely unrecoverable and the test should say so.

Flaky (not blocking)

The 6 flaky entries (beforeunload, video+trace, trace-viewer-scrub, third-party partitioned cookies, prefetch script body) all passed on retry and are unrelated to header parsing. I didn't dig into their history since they aren't failures.

Pre-existing flake / infra

• [firefox] › mcp/cli-session.spec.ts:54 › idle timeout shuts the session down @mcp-windows-latest-firefox — badly flaky on this bot: failed 38 of 125 runs (30%), across dozens of unrelated PRs and pushes (e.g. runs 34656353189, 35195191777, 35407158576). Fails with Expected substring: "- default:" / Received: "(no browsers)" — a session-teardown race, not header parsing.

• [firefox] › mcp/cli-core.spec.ts:149 › upload multiple files @mcp-windows-latest-firefox — failed 7 of 704 runs, previously on PRs feat(video): allow configuring screencast bitrate #42407, chore(trace): remove snapshot pointers from action events #42431, fix(mcp): follow symlinks when checking file access against workspace roots #42628, fix(mcp): keep upload modal, skip short secrets and bad headers #42713, feat(trace-viewer): show screencast frames during playback #42751 and on a push SHA. Error is received value must not be null nor undefined, i.e. the expected response never arrived.

• [chrome] › mcp/cli-webmcp.spec.ts:188 › webmcp-call disambiguates same-name tools in identical same-origin frames @mcp-ubuntu-latest-chrome — failed 2 of 26 runs, the other on push SHA 07f1a61 (run 35414323273), unrelated to this PR. The output shows only frame 2 registered when both frames were expected — a WebMCP registration race.

Uncertain

• [chromium] › mcp/cli-webmcp.spec.ts:162 › webmcp-call disambiguates duplicate tool names by frame @mcp-macos-latest-chromium — this is its only failure in the results DB (1 of 24 runs), so by the numbers alone I can't call it pre-existing. It does fail the same way as its sibling above — the echo tool resolved in a single frame instead of being reported as ambiguous — and this file is only ~25 runs old, so there is little history to lean on. To be sure it's a flake I'd want a re-run of the MCP job, or one more sighting on an unrelated SHA.