feat(webkit): roll to r2365

[microsoft-playwright-automation]

Browser build: https://github.com/microsoft/playwright-browsers/commit/7ca5ef18cf58ab11c21a196f34d5e28e8023a10d. Build has full platform coverage - check that all tests pass there.

[github-actions]

Test results for "tests 1"

2 failed
❌ [installation tests] › playwright-cdn.spec.ts:43 › playwright cdn failover should work (https://cdn.playwright.dev/dbazure/download/playwright) @package-installations-macos-latest
❌ [installation tests] › playwright-cdn.spec.ts:43 › playwright cdn failover should work (https://playwright.download.prss.microsoft.com/dbazure/download/playwright) @package-installations-macos-latest

5 flaky

⚠️ [chromium-library] › library/video.spec.ts:521 › screencast › should capture static page in persistent context Radoslav Kirilov (@smoke) `@chromium-ubuntu-22.04-node20`
⚠️ [chromium-library] › library/chromium/chromium.spec.ts:436 › should produce network events, routing, and annotations for Service Worker (advanced) `@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`

51973 passed, 1247 skipped

---

Merge workflow run.

[github-actions]

Hi, I'm the Playwright bot and I triaged the CI failures on this PR.

🟢 Both failures are a CDN download outage, unrelated to this roll

playwright-cdn.spec.ts:43 fails on package-installations-macos-latest because npx playwright install dies mid-download of Chrome for Testing 154.0.8037.0 (chromium v1246) — nothing to do with WebKit r2365. The same test is red right now on main and on seven unrelated PRs.

Details

This PR only bumps the WebKit revision in packages/playwright-core/browsers.json. The failing download is the Chromium CFT zip, and both failures are the same story across two CDN hostnames, so it's one group.

Pre-existing flake / infra

• [installation tests] › playwright-cdn.spec.ts:43 › playwright cdn failover should work (both the cdn.playwright.dev and playwright.download.prss.microsoft.com variants) — across the aggregated CI results this test is 18 red out of 643 runs on package-installations-macos-latest, and 15 of those 18 landed today, spread over main (6391967, ad9c859, 8bb2c09, 24b6932, bf9d04f) and unrelated PRs fix(trace-viewer): reject unsafe snapshot tag names #42712, fix(reporter): fail perfetto writes when the output stream errors #42715, feat(video): allow recording video at a custom fps #42752, feat(chromium): roll to r1246 #42757, feat(screencast): style action decorations, keep cursor visible #42758, devops(bidi): publish BiDi reports to a git branch instead of Azure #42760. It has also hit the two previous WebKit rolls, feat(webkit): roll to r2364 #42748 and feat(webkit): roll to r2363 #42737, which shared no browser build with this one.

  The error is a truncated transfer, not a 404 — the progress bar stops partway:

  Downloading Chrome for Testing 154.0.8037.0 (playwright chromium v1246) from
  https://cdn.playwright.dev/builds/cft/154.0.8037.0/mac-arm64/chrome-mac-arm64.zip
  |■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■    |  50% of 182.5 MiB
  EXIT CODE: 1
  

  Only the macOS installation bot is affected; the ubuntu and windows installation bots are 0-for-631 on failures for the same test.

• Run history for this test on package-installations-macos-latest, oldest first — green until the cluster starting midday today:

  🟩🟥🟩🟩🟩🟥🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟩🟥🟥🟥🟥🟥🟥🟥🟥🟥🟥🟥🟥🟥🟥

The 5 flaky tests in the report (chromium video/service-worker, firefox partitioned cookies and media emulation) all passed on retry and are on browsers this roll doesn't touch.

Worth noting the WebKit roll itself is effectively unverified on the macOS installation bot, since the run never got past the Chromium download — a rerun once the CDN settles would confirm it.

_{Triaged by the Playwright bot - agent run}

[github-actions]

Test results for "MCP"

1 failed
❌ [chrome] › mcp/sse.spec.ts:171 › sse transport browser lifecycle (persistent, multiclient) @mcp-macos-latest-chrome

8589 passed, 1446 skipped

---

Merge workflow run.

[github-actions]

Hi, I'm the Playwright bot and I triaged the CI failures on this PR.

🟡 One timeout on a Chrome bot — this roll can't plausibly reach it, but I can't call it a known flake

mcp/sse.spec.ts:171 › sse transport browser lifecycle (persistent, multiclient) timed out at 30s on mcp-macos-latest-chrome. This PR changes exactly one line — the WebKit revision 2364 → 2365 in packages/playwright-core/browsers.json — which has no bearing on a Chrome-channel MCP test. But the same test has no failure history I can point at, so I'm calling it uncertain rather than a flake.

Details

Uncertain

• [chrome] › mcp/sse.spec.ts:171 › sse transport browser lifecycle (persistent, multiclient) @mcp-macos-latest-chrome — Test timeout of 30000ms exceeded., duration 30006ms, no retry. It was the only failure on that bot in the run.

  Against the aggregated CI results this exact (project, file, title) is 1 red out of 711 runs on mcp-macos-latest-chrome, and 0 out of ~8500 runs across the other twelve MCP bots — and that single red is this PR's own run. It also passed on all eleven other MCP bots in the very same run (35274543853), including every WebKit bot, which are the ones the new browser build actually affects.

  What keeps this out of the green column: by the same-test rule I need the test failing somewhere this PR can't be responsible for, and I don't have that. What I do have is its neighbours in the same file timing out the same way on unrelated SHAs — sse transport browser lifecycle (isolated, multiclient) on main (d4ce80d) and on 535d8f1, and sse transport browser lifecycle (persistent) on unrelated feat(firefox): roll Firefox to M155 #42445 — so the SSE lifecycle suite does occasionally hang on CI, just not this member of it before now.

  A rerun of the MCP workflow settles it: green on the retry and it's noise, red again on a WebKit-only revision bump and something much stranger is going on.

For the record, the earlier tests 1 report on this PR (the two playwright-cdn.spec.ts:43 failures) is the ongoing CDN download outage and is triaged in my previous comment.

_{Triaged by the Playwright bot - agent run}

[github-actions]

Test results for "tests 2"

39 failed
❌ [chromium-library] › library/coverage.spec.ts:34 › should collect istanbul coverage into the trace @tracing-chromium
❌ [chromium-library] › library/coverage.spec.ts:55 › should collect coverage per trace chunk @tracing-chromium
❌ [chromium-library] › library/coverage.spec.ts:81 › should report maps once and counters incrementally @tracing-chromium
❌ [chromium-library] › library/coverage.spec.ts:109 › should accumulate counters across pulls and keep never hit files @tracing-chromium
❌ [chromium-library] › library/coverage.spec.ts:135 › should collect coverage of a page closed by in-page script @tracing-chromium
❌ [chromium-library] › library/coverage.spec.ts:157 › should not double count a stash picked up twice @tracing-chromium
❌ [chromium-library] › library/coverage.spec.ts:179 › should discard stashes of other sessions @tracing-chromium
❌ [chromium-library] › library/coverage.spec.ts:199 › should collect coverage of an origin left without a page @tracing-chromium
❌ [chromium-library] › library/coverage.spec.ts:229 › should pull counters as the actions go @tracing-chromium
❌ [chromium-library] › library/coverage.spec.ts:246 › should not collect coverage without the option @tracing-chromium
❌ [chromium-library] › library/coverage.spec.ts:259 › should count only the hits after start @tracing-chromium
❌ [chromium-library] › library/coverage.spec.ts:276 › should stop collecting when tracing stops @tracing-chromium
❌ [chromium-library] › library/coverage.spec.ts:293 › should surface a failure to stash the coverage @tracing-chromium
❌ [firefox-library] › library/coverage.spec.ts:34 › should collect istanbul coverage into the trace @tracing-firefox
❌ [firefox-library] › library/coverage.spec.ts:55 › should collect coverage per trace chunk @tracing-firefox
❌ [firefox-library] › library/coverage.spec.ts:81 › should report maps once and counters incrementally @tracing-firefox
❌ [firefox-library] › library/coverage.spec.ts:109 › should accumulate counters across pulls and keep never hit files @tracing-firefox
❌ [firefox-library] › library/coverage.spec.ts:135 › should collect coverage of a page closed by in-page script @tracing-firefox
❌ [firefox-library] › library/coverage.spec.ts:157 › should not double count a stash picked up twice @tracing-firefox
❌ [firefox-library] › library/coverage.spec.ts:179 › should discard stashes of other sessions @tracing-firefox
❌ [firefox-library] › library/coverage.spec.ts:199 › should collect coverage of an origin left without a page @tracing-firefox
❌ [firefox-library] › library/coverage.spec.ts:229 › should pull counters as the actions go @tracing-firefox
❌ [firefox-library] › library/coverage.spec.ts:246 › should not collect coverage without the option @tracing-firefox
❌ [firefox-library] › library/coverage.spec.ts:259 › should count only the hits after start @tracing-firefox
❌ [firefox-library] › library/coverage.spec.ts:276 › should stop collecting when tracing stops @tracing-firefox
❌ [firefox-library] › library/coverage.spec.ts:293 › should surface a failure to stash the coverage @tracing-firefox
❌ [webkit-library] › library/coverage.spec.ts:34 › should collect istanbul coverage into the trace @tracing-webkit
❌ [webkit-library] › library/coverage.spec.ts:55 › should collect coverage per trace chunk @tracing-webkit
❌ [webkit-library] › library/coverage.spec.ts:81 › should report maps once and counters incrementally @tracing-webkit
❌ [webkit-library] › library/coverage.spec.ts:109 › should accumulate counters across pulls and keep never hit files @tracing-webkit
❌ [webkit-library] › library/coverage.spec.ts:135 › should collect coverage of a page closed by in-page script @tracing-webkit
❌ [webkit-library] › library/coverage.spec.ts:157 › should not double count a stash picked up twice @tracing-webkit
❌ [webkit-library] › library/coverage.spec.ts:179 › should discard stashes of other sessions @tracing-webkit
❌ [webkit-library] › library/coverage.spec.ts:199 › should collect coverage of an origin left without a page @tracing-webkit
❌ [webkit-library] › library/coverage.spec.ts:229 › should pull counters as the actions go @tracing-webkit
❌ [webkit-library] › library/coverage.spec.ts:246 › should not collect coverage without the option @tracing-webkit
❌ [webkit-library] › library/coverage.spec.ts:259 › should count only the hits after start @tracing-webkit
❌ [webkit-library] › library/coverage.spec.ts:276 › should stop collecting when tracing stops @tracing-webkit
❌ [webkit-library] › library/coverage.spec.ts:293 › should surface a failure to stash the coverage @tracing-webkit

35 flaky

⚠️ [chromium-page] › page/page-screenshot.spec.ts:504 › page screenshot › should take fullPage screenshots during navigation `@tracing-chromium`
⚠️ [chromium-library] › library/chromium/chromium.spec.ts:213 › should intercept service worker requests (main and within) `@msedge-dev-windows-latest`
⚠️ [chromium-library] › library/downloads-path.spec.ts:32 › downloads path › should keep downloadsPath folder `@msedge-dev-windows-latest`
⚠️ [chromium-page] › page/page-screenshot.spec.ts:723 › page screenshot animations › should stop animations that happen right before screenshot `@msedge-dev-windows-latest`
⚠️ [chromium-library] › library/chromium/chromium.spec.ts:179 › serviceWorker(), and fromServiceWorker() work `@chrome-ubuntu-22.04`
⚠️ [chromium-library] › library/chromium/chromium.spec.ts:213 › should intercept service worker requests (main and within) `@chrome-ubuntu-22.04`
⚠️ [chromium-library] › library/chromium/chromium.spec.ts:436 › should produce network events, routing, and annotations for Service Worker (advanced) `@chrome-ubuntu-22.04`
⚠️ [chromium-library] › library/video.spec.ts:762 › screencast › should work with video+trace `@chromium-windows-latest`
⚠️ [chromium-library] › library/chromium/chromium.spec.ts:179 › serviceWorker(), and fromServiceWorker() work `@chromium-macos-15-large`
⚠️ [chromium-library] › library/chromium/chromium.spec.ts:301 › should report intercepted service worker requests in HAR `@chromium-macos-15-large`
⚠️ [chromium-library] › library/chromium/connect-over-cdp.spec.ts:253 › should send extra headers with connect request `@chromium-macos-15-large`
⚠️ [chromium-library] › library/trace-viewer.spec.ts:1695 › should highlight locator in iframe while typing `@chromium-macos-14-xlarge`
⚠️ [chromium-library] › library/chromium/chromium.spec.ts:179 › serviceWorker(), and fromServiceWorker() work `@chrome-beta-ubuntu-22.04`
⚠️ [chromium-library] › library/selector-generator.spec.ts:569 › selector generator › should not accept invalid role for candidate consideration `@chrome-beta-ubuntu-22.04`
⚠️ [chromium-library] › library/chromium/chromium.spec.ts:213 › should intercept service worker requests (main and within) `@chrome-macos-latest`
⚠️ [chromium-library] › library/selector-generator.spec.ts:102 › selector generator › should not use description when name is unique `@chrome-macos-latest`
⚠️ [chromium-library] › library/selector-generator.spec.ts:297 › selector generator › should use internal:has-text with regexp `@chrome-macos-latest`
⚠️ [chromium-library] › library/trace-viewer.spec.ts:1695 › should highlight locator in iframe while typing `@chrome-macos-latest`
⚠️ [firefox-library] › library/browsercontext-cookies-third-party.spec.ts:257 › third party 'Partitioned;' cookies `@tracing-firefox`
⚠️ [firefox-library] › library/browsercontext-cookies-third-party.spec.ts:470 › top level 'Partitioned;' cookie and same origin iframe `@tracing-firefox`
⚠️ [firefox-library] › library/browsercontext-cookies-third-party.spec.ts:257 › third party 'Partitioned;' cookies `@firefox-macos-15-large`
⚠️ [firefox-library] › library/browsercontext-cookies-third-party.spec.ts:470 › top level 'Partitioned;' cookie and same origin iframe `@firefox-macos-15-large`
⚠️ [firefox-page] › page/page-event-request.spec.ts:181 › should return response body when Cross-Origin-Opener-Policy is set `@firefox-macos-15-large`
⚠️ [firefox-library] › library/browsercontext-cookies-third-party.spec.ts:257 › third party 'Partitioned;' cookies `@firefox-windows-latest`
⚠️ [firefox-library] › library/browsercontext-cookies-third-party.spec.ts:470 › top level 'Partitioned;' cookie and same origin iframe `@firefox-windows-latest`
⚠️ [firefox-library] › library/signals.spec.ts:25 › should close the browser when the node process closes `@firefox-windows-latest`
⚠️ [firefox-library] › library/browsercontext-cookies-third-party.spec.ts:257 › third party 'Partitioned;' cookies `@firefox-macos-15-xlarge`
⚠️ [firefox-library] › library/browsercontext-cookies-third-party.spec.ts:470 › top level 'Partitioned;' cookie and same origin iframe `@firefox-macos-15-xlarge`
⚠️ [firefox-page] › page/expect-timeout.spec.ts:114 › should not miss element that appears between retries before the deadline `@firefox-macos-15-xlarge`
⚠️ [webkit-page] › page/page-autowaiting-basic.spec.ts:79 › should await form-post on click `@tracing-webkit`
⚠️ [webkit-library] › library/trace-viewer-scrub.spec.ts:65 › should cycle playback speed `@webkit-macos-15-xlarge`
⚠️ [webkit-library] › library/trace-viewer.spec.ts:1915 › should not leak recorders `@webkit-macos-15-xlarge`
⚠️ [webkit-library] › library/trace-viewer.spec.ts:1987 › canvas disabled title `@webkit-macos-15-xlarge`
⚠️ [webkit-library] › library/trace-viewer.spec.ts:1997 › canvas clipping `@webkit-macos-15-xlarge`
⚠️ [android-page] › page/page-request-fulfill.spec.ts:81 › should fulfill with unuassigned status codes

106976 passed, 4607 skipped

---

Merge workflow run.

[github-actions]

Hi, I'm the Playwright bot and I triaged the CI failures on this PR.

🟢 All 39 failures are library/coverage.spec.ts, already red on main

The whole coverage suite fails with tracing.start: Tracing has been already started on the three tracing-* bots — including on this PR's own base commit 6391967. A WebKit revision bump can't break Chromium and Firefox tracing.

Details

This PR changes one line: the WebKit revision 2364 → 2365 in packages/playwright-core/browsers.json. The failures are all 13 tests of library/coverage.spec.ts × 3 browsers, failing identically on chromium, firefox and webkit, so it's one group.

Pre-existing flake / infra

• [chromium-library|firefox-library|webkit-library] › library/coverage.spec.ts (all 13 tests, @tracing-chromium / @tracing-firefox / @tracing-webkit) — this is not a flake but a standing breakage. On the tracing-* bots the file is 0 passed out of 728 results across all 14 run attempts in the aggregated CI results, going back to main 05c126b on Sep 16. Every failure is the same:

  Error: tracing.start: Tracing has been already started
  

  It has been red on main at 05c126b, 118ee44, 6480b58, f424484, f1ea64b, bf9d04f, 24b6932, 8bb2c09, ad9c859 and 6391967 — that last one being the base commit of this PR — and on the unrelated Chromium roll feat(chromium): roll to r1246 #42757 (both attempts). Same 13-test block, same error, every time.

  Run history on the tracing-* bots, oldest first, this PR's run last:

  🟥🟥🟥🟥🟥🟥🟥🟥🟥🟥🟥🟥🟥🟥

  The same file is green everywhere tracing isn't forced on — 169 passed and 0 failed per bot on chromium-windows-latest, webkit-macos-15-xlarge, firefox-macos-15-large and the rest — which points at the --trace on bot config colliding with the tracing the tests start themselves, not at anything a browser build controls.

The 35 flaky tests in this report all passed on retry, and the WebKit bots in the same run are not among the failures — the roll itself looks fine so far.

For the record, the two earlier reports on this PR are triaged in my previous comments: the playwright-cdn.spec.ts:43 failures are the ongoing CDN download outage (🟢), and the single mcp/sse.spec.ts:171 timeout on mcp-macos-latest-chrome is still 🟡 uncertain — a rerun of the MCP workflow would settle it.

_{Triaged by the Playwright bot - agent run}