fix(firefox): preserve response header field boundaries

[Devin Rousso (dcrousso)]

splitting response headers on commas corrupts values and invents field boundaries

use the original fields reported by Juggler without parsing them again

reuse Chromium's Set-Cookie splitter for fulfillment so multiple cookies remain separate fields

work towards #42687

[github-actions]

🔴 All 8 failures look caused by this PR

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

Every failure is Firefox-only and lands squarely on response header splitting — including the four tests this PR adds. Dropping parseMultivalueHeaders() means Juggler's combined field values are now passed through verbatim on the observed response path; splitSetCookieHeader() is only applied on the fulfillment path (FFRouteImpl.fulfill), so Set-Cookie arrives as one \n-joined entry.

Details

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.

_{Triaged by the Playwright bot - agent run}

[github-actions]

🟡 Almost certainly flakes — one I can't prove

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

None of the 4 failures touch response headers: this PR only changes Firefox/Chromium header field handling, and the failing tests assert on browser listing, file upload, and WebMCP frame disambiguation. Three of them have a documented history of failing on other SHAs; the fourth has no history either way.

Details

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.

_{Triaged by the Playwright bot - agent run}

[github-actions]

Test results for "tests 1"

4 flaky

⚠️ [chromium-library] › library/browsercontext-page-event.spec.ts:173 › should work with Ctrl-clicking `@chromium-ubuntu-22.04-arm-node20`
⚠️ [chromium-page] › page/workers.spec.ts:191 › should attribute network activity for worker inside iframe to the iframe `@chromium-ubuntu-22.04-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`

52544 passed, 1270 skipped

---

Merge workflow run.

[github-actions]

Test results for "MCP"

8937 passed, 1489 skipped

---

Merge workflow run.

[Yury Semikhatsky (yury-s)]

aren't they already split here? My understanding is that now we pass split cookies between playwright and browser, but at which point can we glue them together so that this split is necessary?

[Devin Rousso (dcrousso)]

route.fulfill({ response }) uses APIResponse.prototype.headers which joins Set-Cookie values with \n so we still need to split them before fulfillment