fix(chromium): allow more screencast frames in flight

[Dmitry Gozman (dgozman)]

Summary

• Chromium stops capturing screencast frames once 3 frames are sent without an ack. Under heavy load the ack is occasionally delayed by 30-50ms, which drops frames from the recording.
• Pass maxFramesInFlight: 5 to Page.startScreencast, and 10 when recording at more than 30 fps. Plumb fps from the screencast client to the page delegate for that.
• Measured with 20 headless browsers recording 60fps in parallel on a saturated CPU: 6 of 20 recordings dropped a frame before, none after.

[github-actions]

Test results for "tests 1"

4 flaky

⚠️ [chromium-library] › library/browsercontext-page-event.spec.ts:173 › should work with Ctrl-clicking `@chromium-ubuntu-22.04-arm-node20`
⚠️ [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`
⚠️ [playwright-test] › ui-mode-trace.spec.ts:778 › should partition action tree state by test `@windows-latest-node22`

52280 passed, 1255 skipped

---

Merge workflow run.

[github-actions]

Test results for "MCP"

1 failed
❌ [firefox] › mcp/cli-parsing.spec.ts:88 › should preserve leading zeros in string arguments @mcp-windows-latest-firefox

8750 passed, 1480 skipped

---

Merge workflow run.

[github-actions]

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

🟢 The one failure is a pre-existing flake

mcp/cli-parsing.spec.ts:88 on Windows Firefox has failed the same way on other PRs and on main, and this PR's Chromium screencast changes don't reach it.

Details

The latest reports for head eec3389 show one hard failure (MCP) and only flaky tests in "tests 1". This PR changes screencast frame handling (crPage.ts, screencast.ts, videoRecorder.ts, page.ts, pageDispatcher.ts). That is Chromium screencast/video code, and a Firefox MCP CLI typing test doesn't exercise it.

Pre-existing flake / infra

• [firefox] › mcp/cli-parsing.spec.ts:88 › should preserve leading zeros in string arguments (mcp-windows-latest-firefox). The test-results DB has this exact test failing with the same error elsewhere: Expected substring: "0812345679", Received string: "- textbox [ref=e2]". That means the snapshot was taken before the typed text showed up in the input.
  • Windows Firefox, on unrelated PRs: feat(mcp): expose page-registered WebMCP tools #42613 (run), fix(mcp): do not close browser while tool call is running #42696 (run), fix typo Provisional instead of Provisiolal #42829 (run) and feat(webkit): roll to r2366 #42879 (run).
  • macOS Firefox, on a main push (run). Retries also rescued it on macOS and Ubuntu Firefox.
  • Overall it failed on a few of ~380 Windows Firefox runs and passed the rest.

The test types into the input and then takes a snapshot right away, with no wait in between. That looks like a timing race in the test, not a product regression.

_{Triaged by the Playwright bot - agent run}