[Feature]: pass maxFramesInFlight through to Page.startScreencast

Open
#42,809 0 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Assessment

Difficulty
5/5
Estimated time
Over a week
Newbie friendliness
38/100
Issue type
Feature
Clarity
Mostly clear
Activity status
Active
Tech stack
typescript
Domain
api

Research direction

Start at the page.screencast.start() API and the Chromium delegate that sends Page.startScreencast parameters; compare the corresponding Firefox and WebKit paths. First resolve whether the option is browser-specific or a shared throughput hint, then add the API, documentation, and coverage for passing maxFramesInFlight through and preserving behavior in the other browsers.

Written by the indexing model from the issue text.

Description

🚀 Feature Request

Chromium 154 added maxFramesInFlight to Page.startScreencast, defaulting to 3. Playwright's Chromium delegate sends format, quality, maxWidth and maxHeight, so the parameter is not reachable through page.screencast.start().

What it costs. Recording a 2560×1600 page at 60 fps, measured on stock Chrome for Testing 154.0.8037.0, three interleaved repeats of the same run: at the default of 3 we capture 86.6 % of the frames Chromium reports it presented (89.5 / 82.2 / 88.0 %); at 12 we capture 98.8 % — 338 of 342, three times out of three. The loss is not evenly spread and it is visible in the finished video, not merely countable.

Why the userland route does not cover this one. We are aware of the position in #41007 — that recording knobs belong in userland via page.screencast.start({ onFrame }), and that shipping them constrains Playwright's own implementation. That reasoning holds for everything downstream of the frame: encoding, bitrate, container. This parameter acts upstream of it — it decides whether the browser hands the frame over at all — and onFrame is on the wrong side of that line. It is also not an API of Playwright's own making: Chromium exposes it, so passing it through does not lock in any implementation choice.

The design question we cannot answer for you. page.screencast covers three browsers and this is a Chromium term; Firefox and WebKit send { width, height, quality } at the same place. We would propose a generally-worded throughput hint that the other two ignore, but a browser-specific option, or simply a better default at large capture sizes, would all work for us. Which shape do you want?

We would like to implement it, docs and test included, once an issue is assigned.

Our current workaround is to drive the screencast over context.newCDPSession(page) ourselves, which works but means giving up page.screencast entirely.

Dominant language
TypeScript
Stars
96.4k
Forks
6.5k
Avg merge
1d 7h
Merged PRs (30d)
170

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from microsoft/playwright

All issues in microsoft/playwright

Similar issues

More TypeScript issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.