feat(browserContext): support maximized viewport by dcrousso · Pull Request #42286 · microsoft/playwright

Devin Rousso (dcrousso) · 2026-08-17T21:55:38Z

allow viewport: 'maximized' to maximize native browser windows without a default emulated viewport

keep native maximization independent of browser fullscreen and the web Fullscreen API

preserve the maximized outer window when Page.setViewportSize() enables viewport emulation

github-actions · 2026-08-18T22:33:50Z

🟢 CI is clear — the one failure is a pre-existing Windows flake

Hi, I'm the Playwright bot and I took a look at the failing CI on this PR. The single red test — playwright.trace.spec.ts:434 › should retain traces for interrupted tests on [playwright-test] @windows-latest-node22 — is a known Windows-only flake, unrelated to this PR's windowState change. Nothing here looks caused by the PR.

Details

This PR adds a windowState browser-context option (touching browserContext.ts, crPage.ts, ffBrowser.ts, wkPage.ts, protocol, and headful.spec.ts). It doesn't go near the test runner's trace-retention path that this test exercises.

Pre-existing flake / infra

[playwright-test] › playwright.trace.spec.ts:434 › should retain traces for interrupted tests — flake. In the aggregated CI results it flips verdict only on windows-latest-node22: failed 4 of 658 runs there (~0.6%), passed the other 654, and never fails on any other bot (0 failures across all Linux/macOS runners). The 4 failures are on SHAs this PR can't be responsible for — main (43a91219, 40372734) and PRs feat(test-runner): annotate serial suites for custom sharding #42164 (4e5071fd) and fix(chromium): keep closing the target so page.close() cannot hang on a navigation commit #41912 (21e8d31e), none of which touch windowState. Every failure carries the same signature (expect(received).toBe(expected) / Expected: 1, Received: 0 — a missing trace on a timing-sensitive interrupted-test check), which is the classic shape of this flake. Windows-only, on unrelated SHAs → not PR-specific.

The other 22 tests in the report are within-run flakes (rescued on retry), so there's nothing to triage there.

_{Triaged by the Playwright bot - agent run}

Dmitry Gozman (dgozman) · 2026-09-04T10:48:45Z

+    await context.close();
+  });
+
+  it('should keep native window maximized when resizing viewport', async ({ browser, browserName }) => {


What does this mean for the user? How does it look?

page.setViewportSize() sets a fixed inner viewport without resizing the maximized native window leaving unused space around the 567x345 page

This sounds very strange to me. I'd assume that setViewportSize() completely disregards the viewportSize option from the context settings. It does so for WxH values, and for null values, so it should do the same for maximized?

Dmitry Gozman (dgozman) · 2026-09-04T10:51:55Z

+    await context.close();
+  });
+
+  it('should open popups in maximized windows', async ({ browser, browserName, server }) => {


I'd like to also understand the expected behavior of things like "shift+click" that opens a new window, or window.open('', '_blank', 'left=100,top=100,width=320,height=320').

maximizing should override popup geometry for shift-click and explicitly sized window.open()

i've added tests for both

allow `viewport: 'maximized'` to maximize native browser windows without a default emulated viewport keep native maximization independent of browser fullscreen and the web Fullscreen API preserve the maximized outer window when `Page.setViewportSize()` enables viewport emulation

github-actions · 2026-09-09T22:15:32Z

Test results for "tests 1"

4 flaky

⚠️ [chromium-library] › library/popup.spec.ts:260 › should not throw when click closes popup `@realtime-time-library-chromium-linux`
⚠️ [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-event-request.spec.ts:181 › should return response body when Cross-Origin-Opener-Policy is set `@firefox-ubuntu-22.04-node20`

51521 passed, 1286 skipped

Merge workflow run.

github-actions · 2026-09-09T22:15:51Z

Test results for "MCP"

3 failed
❌ [chromium] › mcp/http.spec.ts:105 › http transport browser lifecycle (isolated) @mcp-ubuntu-latest-chromium
❌ [firefox] › mcp/annotate.spec.ts:269 › should start dashboard and annotate when no dashboard is running @mcp-windows-latest-firefox
❌ [msedge] › mcp/annotate.spec.ts:496 › should disengage annotate mode when --annotate client disconnects @mcp-windows-latest-msedge

8345 passed, 1376 skipped

Merge workflow run.

github-actions · 2026-09-09T22:19:36Z

🟢 CI is clear — every failure is a pre-existing flake

Hi, I'm the Playwright bot and I took a look at the failing CI on this PR. All three red tests are MCP flakes that fail on unrelated PRs and on main pushes too, and this PR only touches viewport / browser-window code — nothing the MCP http-transport or annotate flows exercise. Nothing here looks caused by your change.

Details

The tests 1 report has no real failures — its 4 red entries are all flaky (rescued on retry). The MCP report has 3 failures, all pre-existing flakes per the aggregated results DB:

Pre-existing flake / infra

[chromium] › mcp/http.spec.ts:105 › http transport browser lifecycle (isolated) — timeout flake. Fails 15 of 3588 runs across 307 different PRs, including PRs chore(trace-viewer): only offer "Display Aria" when the trace has both snapshot kinds #42435, chore: remove fix flakes bot - it is noise #42432, feat(test-runner): annotate serial suites for custom sharding #42164 and several main pushes (pr=null).
[firefox] › mcp/annotate.spec.ts:269 › should start dashboard and annotate when no dashboard is running — flake. Fails 11 of 3588 runs, e.g. on PR docs(browsercontext): undeprecate setHTTPCredentials #42419, fix(mcp): do not run heartbeat for clients without the event stream #42189 and a main push.
[msedge] › mcp/annotate.spec.ts:496 › should disengage annotate mode when --annotate client disconnects — flake. Fails 3 of 3588 runs, including a main push (pr=null).

This PR changes viewport: 'maximized' handling in browserContext, crPage, wkPage and ffBrowser — the MCP dashboard/http paths don't touch any of that, and the same tests fail on SHAs the PR can't be responsible for. No action needed on CI's account.

_{Triaged by the Playwright bot - agent run}

Devin Rousso (dcrousso) requested review from Pavel Feldman (pavelfeldman) and Yury Semikhatsky (yury-s) August 17, 2026 21:55