fix(network): resolve response.finished() when the request fails after the response

[Dashgin Khudiyev (dashgin)]

Fixes #42786

Chromium ends a fetch answered with 204 No Content in Network.loadingFailed (net::ERR_ABORTED), even though the page's fetch resolves normally. The request emits response, then requestfailed. Response.finished() only resolved on requestFinished, so it never resolved. Playwright MCP's post-action wait awaits finished() for every fetch a click starts, so each such click ran into its 5 s cap.

The server already treats this case as finished: crNetworkManager._onLoadingFailed calls response._requestFinished() when a response exists. The client didn't mirror that. It now resolves response.finished() on requestFailed too, when a response exists, which also matches the documented contract ("returns always null").

Test. should resolve finished() for a 204 response in page-event-network.spec.ts. On Chromium it times out without the change and passes with it.

Checked locally (macOS):

• page-event-network, page-event-request, page-network-*, page-request-*, network-post-data, browsercontext-network-event: Chromium 210 passed, Firefox 209, WebKit 204; skips are the existing per-browser skips
• MCP click, core, form, type, wait, network, autowait: 38 passed
• Repro from the issue against the local MCP build: the 204 click went from 6.04 s to 1.06 s, the same as the 200 click

The Python client resolves finished the same way (only in _on_request_finished), so it needs the same one-line change; I haven't checked Java or .NET.

[Dashgin Khudiyev (dashgin)]

@microsoft-github-policy-service agree

[github-actions]

Test results for "tests 1"

7 flaky

⚠️ [chromium-library] › library/video.spec.ts:521 › screencast › should capture static page in persistent context Radoslav Kirilov (@smoke) `@chromium-ubuntu-22.04-arm-node20`
⚠️ [chromium-library] › library/video.spec.ts:690 › screencast › should capture full viewport `@chromium-ubuntu-22.04-arm-node20`
⚠️ [chromium-library] › library/chromium/oopif.spec.ts:311 › should click `@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-emulate-media.spec.ts:144 › should keep reduced motion and color emulation after reload `@firefox-ubuntu-22.04-node20`
⚠️ [firefox-page] › page/page-goto.spec.ts:90 › should work with Cross-Origin-Opener-Policy `@firefox-ubuntu-22.04-node20`

52026 passed, 1250 skipped

---

Merge workflow run.

[github-actions]

Test results for "MCP"

6 failed
❌ [chrome] › mcp/cli-webmcp.spec.ts:162 › webmcp-call disambiguates duplicate tool names by frame @mcp-macos-latest-chrome
❌ [firefox] › mcp/cli-core.spec.ts:140 › uncheck @mcp-windows-latest-firefox
❌ [firefox] › mcp/cli-core.spec.ts:276 › click button with role locator @mcp-windows-latest-firefox
❌ [firefox] › mcp/cli-core.spec.ts:290 › click button with test id locator @mcp-windows-latest-firefox
❌ [firefox] › mcp/cli-devtools.spec.ts:86 › request shows full request and response details @mcp-windows-latest-firefox
❌ [firefox] › mcp/cli-save-as.spec.ts:26 › screenshot @mcp-windows-latest-firefox

8686 passed, 1474 skipped

---

Merge workflow run.

[Dashgin Khudiyev (dashgin)]

The two failing MCP jobs look unrelated to this change:

• windows-latest - firefox: the same job fails on main too, in 3 of the last 6 runs (1, 2, 3).
• macos-latest - chrome: cli-webmcp.spec.ts › "disambiguates duplicate tool names by frame" called the tool before the iframe registered its own. It passed on the other platforms.