feat(network): add request.body async getters for blob request bodies

[yury-s]

Summary

• Chromium and WebKit only report hasPostData for blob-backed request bodies on Network.requestWillBeSent; fetch such bodies asynchronously via Network.getRequestPostData
• Restore request.body()/bodyBuffer()/bodyJSON() async getters from feat: add request.body async getters #38179 and deliver the asynchronously fetched bodies through them; postData* are marked discouraged
• WebKit support requires build 2337

Fixes #6479

[github-actions]

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

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

The two failing tests both flake on their own across unrelated runs, and never on this PR's SHA (61b4c36). This PR touches Chromium/WebKit network post-data reporting and adds request.waitForPostBody() — neither failing test exercises any of it.

Details

Overall: the newest "tests 1" report is 1 failed / 50240 passed; the concurrent MCP report is 1 failed / 7759 passed. No CI signal attributable to this PR.

Pre-existing flake / infra

• [webkit-page] › page/page-leaks.spec.ts:164 › waitFor should not leak — flake. This is a DOM leak test: it asserts that <button> elements are garbage-collected (checkWeakRefs(page, 'button')) and issues no POST requests, so the diff's post-data path can't reach it. In the aggregated test-results DB it's bimodal on this exact bot: webkit-page failed 3 of 452 runs, passed 449 — the three failures land on PR feat(expect): add expect.fn() mock functions with awaited assertions #41884 (×2) and PR test(components): restore web and html-reporter component tests #41889, all on webkit-ubuntu-22.04-node20, none on this PR.

• [chrome] › mcp/annotate.spec.ts:57 › should capture multiple screenshots in one annotation — flake. Across the DB it flips verdict on unrelated SHAs: chrome failed 5 of 339 runs, firefox 2/333, webkit 1/340, chromium 1/337 — the chrome failures are on PRs fix(webview): support input for elements inside cross-origin <iframe> #41463, test(screenshot): fix flaky "event loop is blocked" test #41688, fix(network): request.postData() returns null for empty string body override #41882 and push commits, never on 61b4c36. The MCP annotate flow doesn't touch crNetworkManager.ts / wkPage.ts / server network.ts post-data handling.

I'm a first pass, not the final word — but the diff is confined to Blob/File post-data reporting plus page-network-request.spec.ts, and both flakes have history on other PRs, so I don't see anything here caused by this change.

_{Triaged by the Playwright bot - agent run}

[github-actions]

Test results for "MCP"

1 failed
❌ [chromium] › mcp/cli-test.spec.ts:76 › debug test with custom fixture using browser.newContext @mcp-windows-latest-chromium

7785 passed, 1249 skipped

---

Merge workflow run.

[github-actions]

Test results for "tests 1"

2 flaky

⚠️ [chromium-library] › library/video.spec.ts:664 › screencast › should capture full viewport `@chromium-ubuntu-22.04-arm-node20`
⚠️ [chromium-library] › library/chromium/chromium.spec.ts:434 › should produce network events, routing, and annotations for Service Worker (advanced) `@chromium-ubuntu-22.04-node24`

50115 passed, 1192 skipped

---

Merge workflow run.

[github-actions]

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

🟡 One failure I can't tie to this PR — but can't yet call a flake either

[chromium] › mcp/cli-test.spec.ts:76 › debug test with custom fixture using browser.newContext (mcp-windows-latest-chromium) is the only failure in the latest report. Nothing in the diff reaches it, but it's the only occurrence in the results DB and it's on this PR's own SHA — so I can't prove it's pre-existing.

Details

Overall: the newest merged report ("MCP") is 1 failed / 7785 passed. The diff is confined to Blob/File POST-data reporting — network.ts (deferPostData/resolvePostData/body), crNetworkManager.ts, wkPage.ts — plus the new tests/page/network-request-body.spec.ts. The server additions are inert unless deferPostData() fires on the Chromium/WebKit blob path, so they don't change general request handling.

Uncertain

• [chromium] › mcp/cli-test.spec.ts:76 › debug test with custom fixture using browser.newContext — the test does setContent('<button>Submit</button>') then snapshot, and asserts the snapshot contains button "Submit". It issues no POST request, so the diff's post-data path can't reach it. The failure signature is infra-flavored: expect(received).toContain("button \"Submit\"") with received empty ("") — the debug CLI attach returned an empty snapshot.

  What keeps this from a green flake verdict: in the aggregated results DB this (project, file, title) has failed exactly once across 3,346 runs, and that one failure is on head_branch: fix-6479, pr_number: 41888 (SHA 850220b) — this very PR. Every other bot and OS is 0 failures. Per our own rule, calling something a flake needs the same test failing somewhere the PR can't be responsible for, and I don't have that here.

  My read: almost certainly a harness hiccup in the debug-CLI snapshot rather than something this change caused — but I'd want to see it either reproduce off this branch or clear on a rerun before certifying it green. A rerun of the mcp-windows-latest-chromium job would settle it.

_{Triaged by the Playwright bot - agent run}