fix(webkit): allow service worker navigation while offline

[Devin Rousso (dcrousso)]

offline emulation rejects navigation even when a service worker supplies the response

apply configured offline state when page targets are initialized

cover service worker responses, context isolation, and reopening pages

fixes #42775

[github-actions]

Test results for "tests 1"

4 failed
❌ [webkit-library] › library/browsercontext-service-worker-policy.spec.ts:35 › should allow literal service worker navigation while offline @webkit-ubuntu-22.04-node20
❌ [webkit-library] › library/browsercontext-service-worker-policy.spec.ts:35 › should allow cache-only service worker navigation while offline @webkit-ubuntu-22.04-node20
❌ [webkit-library] › library/browsercontext-service-worker-policy.spec.ts:35 › should allow network-fallback service worker navigation while offline @webkit-ubuntu-22.04-node20
❌ [webkit-library] › library/browsercontext-service-worker-policy.spec.ts:35 › should allow preload-fallback service worker navigation while offline @webkit-ubuntu-22.04-node20

2 flaky

⚠️ [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`

52184 passed, 1243 skipped

---

Merge workflow run.

[github-actions]

🔴 The failures are this PR's own new tests

All four failures are the should allow <mode> service worker navigation while offline tests added in this PR, failing on webkit-library — the exact engine the fix targets. Nothing pre-existing here.

Details

Caused by this PR

• [webkit-library] › library/browsercontext-service-worker-policy.spec.ts:35 › should allow {literal,cache-only,network-fallback,preload-fallback} service worker navigation while offline (@webkit-ubuntu-22.04-node20) — these four tests are new in this PR, and WebKit is the one browser they're neither skipped nor fixme'd on. Every mode fails, including literal, where the worker never touches the network — so this isn't one flaky variant, it's the shared assertion that an offline navigation still gets served by the service worker.

  The product change is one line in wkPage.ts: Network.setEmulateOfflineState is now also sent with offline: false at page init instead of only when offline is true. That fixes state leaking into freshly-opened pages, but it doesn't change what WebKit does once offline: true is set — the navigation is still rejected in the network process before the service worker's fetch handler can respond, which is the actual complaint in [Bug]: WebKit offline emulation rejects service-worker navigation, including a literal response #42775. So the tests assert behaviour the fix doesn't yet deliver.

  Worth confirming which assertion trips (response.status(), fromServiceWorker(), or the networkRequests count) — the run's only artifact is the HTML report, and the error text isn't reachable from it.

Not part of the verdict

• The two firefox-library › browsercontext-cookies-third-party.spec.ts entries (:257, :470) are reported flaky, not failed — they passed on retry, and this PR touches no cookie code.

_{Triaged by the Playwright bot - agent run}

[github-actions]

Test results for "MCP"

2 failed
❌ [chromium] › mcp/cli-webmcp.spec.ts:188 › webmcp-call disambiguates same-name tools in identical same-origin frames @mcp-macos-latest-chromium
❌ [firefox] › mcp/cli-core.spec.ts:131 › check @mcp-windows-latest-firefox

8703 passed, 1474 skipped

---

Merge workflow run.

[github-actions]

🟢 Both MCP failures are known flakes

Hi, I'm the Playwright bot — I triaged the "MCP" report. Both failures are tests that flip
verdict on unrelated SHAs, and neither runs anywhere near this PR's WebKit-only change.

Details

This PR changes one line of packages/playwright-core/src/server/webkit/wkPage.ts plus two
tests/library/ specs. The two failures are in chromium and firefox MCP projects — no
WebKit, no shared helper the diff touches. Nothing in the diff can reach them.

Pre-existing flake / infra

• [chromium] › mcp/cli-webmcp.spec.ts:188 › webmcp-call disambiguates same-name tools in identical same-origin frames (@mcp-macos-latest-chromium) — fails 4 of 108 runs on this bot, with the identical expect(received).toContain(expected) / Expected substring: "- frame: http://localhost:8907/wi…" error on SHAs this PR can't touch: pushes e8df678b and e5d880b0, and #42836. Same story on the sibling bots (mcp-macos-latest-chrome 5/109, mcp-ubuntu-latest-chrome 4/113) — a frame-ordering race in the snapshot, not a WebKit offline fix.

• [firefox] › mcp/cli-core.spec.ts:131 › check (@mcp-windows-latest-firefox) — fails 11 of 705 runs, only ever on this one bot (0 failures across the other 14 MCP bots, ~10k runs). Same Expected substring: "- checkbox [checked] [active] [re…" error on unrelated pushes (b8627f95, 9ae53771) and on #42709, #42685, #42562, #42514, #42478, #42425 — going back to mid-August. Looks like a Firefox-on-Windows focus/[active] timing wobble.

One caveat on the headline: this verdict covers the MCP report only. The earlier "tests 1"
report on this PR has four real webkit-library failures in the specs this PR adds — that one
still stands.

_{Triaged by the Playwright bot - agent run}