test: update webkit expectations for NWLoader on macOS

[Yury Semikhatsky (yury-s)]

WebKit on macOS is switching from the legacy CFNetwork loader to NWLoader (microsoft/playwright-browsers#2470). Two test expectations change:

• page-network-sizes.spec.ts "should have the correct responseBodySize for chunked request": NWLoader reports the correct 5175 (the legacy loader undercounted the chunked encoding bytes as 5173). Transitionally accepts both values until the NWLoader-based build ships, then can be tightened to 5175.
• har-websocket.spec.ts "should include websocket handshake headers and status": marked fixme for webkit on macOS 26+ — NWLoader there does not reflect the wire handshake headers (Sec-WebSocket-Key, Connection, Upgrade) in NSURLSessionWebSocketTask.currentRequest, so they are missing from the reported handshake request. macOS 15 is unaffected.

Refernce https://github.com/microsoft/playwright-browsers/issues/2464

[github-actions]

Test results for "tests 1"

2 failed
❌ [installation tests] › playwright-packages-install-behavior.spec.ts:81 › playwright should work with chromium --no-shell @package-installations-macos-latest
❌ [installation tests] › playwright-packages-install-behavior.spec.ts:90 › playwright should work with chromium --only-shell @package-installations-macos-latest

5 flaky

⚠️ [installation tests] › playwright-packages-install-behavior.spec.ts:99 › @playwright/test should work `@package-installations-macos-latest`
⚠️ [chromium-library] › library/video.spec.ts:664 › screencast › should capture full viewport `@chromium-ubuntu-22.04-node20`
⚠️ [chromium-library] › library/chromium/chromium.spec.ts:177 › serviceWorker(), and fromServiceWorker() work `@chromium-ubuntu-22.04-node22`
⚠️ [firefox-page] › page/page-emulate-media.spec.ts:144 › should keep reduced motion and color emulation after reload `@firefox-ubuntu-22.04-node20`
⚠️ [playwright-test] › ui-mode-trace.spec.ts:715 › should indicate current test status `@windows-latest-node22`

51041 passed, 1190 skipped

---

Merge workflow run.

[github-actions]

Test results for "MCP"

2 failed
❌ [chromium] › mcp/cli-drag.spec.ts:19 › drag between elements @mcp-macos-latest-chromium
❌ [webkit] › mcp/http.spec.ts:105 › http transport browser lifecycle (isolated) @mcp-ubuntu-latest-webkit

8087 passed, 1284 skipped

---

Merge workflow run.

[github-actions]

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

🟢 Both failures are infra — this PR is clear

The two playwright-packages-install-behavior.spec.ts failures are Chrome-for-Testing download failures from cdn.playwright.dev on the macOS installation bot, not anything this PR touches. This PR only relaxes two WebKit/macOS network test expectations.

Details

Pre-existing flake / infra

• [installation tests] › playwright-packages-install-behavior.spec.ts:81 › playwright should work with chromium --no-shell and :90 › --only-shell (both @package-installations-macos-latest) — both fail with npx playwright install ... EXIT CODE: 1 → Failed to download Chrome for Testing 152.0.7977.8 ... Download failure, code=1, after retrying the download five times. That's a CDN/network failure fetching the Chromium binary, independent of the test's own code.
• History backs this up: across the aggregated CI results each test failed 1 of 2906 runs — and that single failure is this PR's run. The only other failures of these two titles in the DB are Error: read ECONNRESET on unrelated SHAs (no PR), i.e. the same download-path flakiness surfacing on other bots.
• The diff can't reach these: it changes tests/library/har-websocket.spec.ts and tests/page/page-network-sizes.spec.ts (WebKit responseBodySize and a WebKit-on-macOS-26 websocket-header fixme). Nothing in it affects Chromium binary download or the installation flow.

The 5 flaky entries all passed on retry and are unrelated to the diff, so there's nothing to triage there.

_{Triaged by the Playwright bot - agent run}

[github-actions]

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

🟢 The failures are pre-existing flakes — this PR is clear

All four failures are in areas the diff doesn't touch (chromium package installs, MCP drag/http), and each has a flake history on SHAs this PR can't be responsible for. This PR is a test-only change to two WebKit-on-macOS expectations (har-websocket.spec.ts, page-network-sizes.spec.ts), so it can't reach any of them.

Details

Overall: the PR only relaxes/skips two WebKit-macOS network expectations. None of the four failing tests live in those files or exercise the WebKit network loader, and all four flip verdict across unrelated runs.

Pre-existing flake / infra

• [installation tests] › playwright-packages-install-behavior.spec.ts:81 › playwright should work with chromium --no-shell and :90 › --only-shell (@package-installations-macos-latest) — chromium package-install tests on macOS. Both flake elsewhere: --no-shell was rescued on retry on push sha 30d5b2ec (run 30585190825), --only-shell on push sha 2d9df072 (run 28955218250). A sibling in the same file (:99 › @playwright/test should work) also flaked (passed on retry) in this very report, pointing at the macOS install environment. A test-only WebKit-macOS diff can't affect chromium installs.
• [chromium] › mcp/cli-drag.spec.ts:19 › drag between elements (@mcp-macos-latest-chromium) — failed 1 of 3405 runs across the results DB, the other failure being push sha 9a19b13f (run 30934926479), unrelated to this PR.
• [webkit] › mcp/http.spec.ts:105 › http transport browser lifecycle (isolated) (@mcp-ubuntu-latest-webkit) — failed 14 of 3405 runs, on PRs 41637 / 41688 / 41712 and a push, none related to this change. It's the MCP HTTP transport lifecycle, which this diff doesn't touch.

_{Triaged by the Playwright bot - agent run}

[Devin Rousso (dcrousso)]

is this fixable? or will it be the reality going forward?

[Yury Semikhatsky (yury-s)]

I don't know, at the first glance it seem to be a problem with NWLoader and should be fixed there, but maybe there is a workaround. I filed #42205 and assigned to you, as this is a recent addition.