feat(tracing): allow configuring the screenshots size - #42283
Conversation
All screencast clients of a page share a single browser capture, sized
by whichever client attached first. Tracing attaches per page without
requesting a size, so with tracing on the capture stays at the default
viewport-fit while a later screencast.start({ size }) still encoded the
video at the requested size. The ffmpeg filter pads rather than scales,
so the smaller frames landed top-left with gray filling the rest.
Encode into the size the capture actually runs at instead, so the size
option is plainly ignored rather than half-applied. Document that
tracing captures screenshots through the same screencast.
Fixes: microsoft#42274
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
🟢 The one failure is a pre-existing flake — this PR is clearHi, I'm the Playwright bot and I took a first look at the CI failures. The only non-flaky failure, DetailsPre-existing flake / infra
The other 25 entries in the report are flaky (passed on retry), so there's nothing else to triage. Notably the screencast-adjacent ones — I'm a first pass, not the final word — but I couldn't find any failure that this PR is responsible for. Triaged by the Playwright bot - agent run |
Tracing captures screenshots through the page screencast, which is shared
with screencast.start() and video recording and sized by whoever started
it first. Tracing always requested the default viewport-fit size, capping
what the other consumers could get with no way to opt out.
Let screenshots take an object with a size, so a test that needs a larger
capture can raise it: tracing.start({ screenshots: { size } }). The trace
viewer renders the timeline preview at a fixed size, so this only affects
what the other consumers of the capture receive.
Also skip the "empty video" test under trace=on: with tracing already
capturing, the recorder receives a frame and the video is not empty. It
only passed because the test happened to run before a frame arrived.
Yury Semikhatsky (yury-s)
changed the title
Yury Semikhatsky (yury-s)
changed the title
Review feedback: name the object-taking option `screencast` to match the protocol and `screencast.start()`, leave `screenshots` as the plain boolean it has always been, and accept `quality` alongside `size` so tracing can configure the shared capture the same way `screencast.start()` does. `screencast` takes precedence when both are given.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
Test results for "MCP"1 failed 8100 passed, 1311 skipped Merge workflow run. |
🟢 Every failure is a pre-existing flake — this PR is clearHi, I'm the Playwright bot and I took a look at the CI failures. Across the reports there are three real failures — DetailsThis PR only touches trace/video screencast sizing ( Pre-existing flake / infra
Note: the newest I'm a first pass, not the final word — but I couldn't find any failure this PR is responsible for. Triaged by the Playwright bot - agent run |
Test results for "tests 1"18 flaky51172 passed, 1227 skipped Merge workflow run. |
b856094
into
microsoft:main
2 participants
Summary
tracing.start({ screenshots: { size } }), and the same under thetracetest option. Tracing shares one screencast per page withscreencast.start()and video recording, but always requested the default viewport-fit size, capping what the others could get with no way to opt out. The trace viewer renders the timeline preview at a fixed size, so this only affects those other consumers.screencast.start({ size })encoded the video at the requested size while receiving smaller frames — ffmpeg pads rather than scales, leaving gray borders. Encode into the size the capture actually runs at instead, sosizeis plainly ignored rather than half-applied.Fixes #42274