[Regression]: middle / modifier click intermittently fails to open a new tab on Playwright 1.62.x

[YuriiMotov]

Last Good Version

1.61.1

First Bad Version

1.62.0

Steps to reproduce

1. git clone https://github.com/YuriiMotov/playwright-1.62-new-tab-mre.git
2. cd playwright-1.62-new-tab-mre
3. npm install
4. npx playwright --version - expected Version 1.62.1
5. npx playwright test --repeat-each=25 --workers=16 - see several tests fail with Test timeout of 30000ms exceeded
6. Downgrade to latest working version: npm pkg set devDependencies.@playwright/test=1.61.1 && npm install
7. npx playwright --version - expected Version 1.61.1
8. npx playwright test --repeat-each=25 --workers=16 - see tests pass

Expected behavior

I expect tests pass on 1.62.x as it was on 1.61.1 and previous versions.

Actual behavior

Several tests fail with Test timeout of 30000ms exceeded

Additional context

Only tests that attempt to open page in a new tab are affected.

--workers=16 here is to imitate overloaded machine. In fact in our case it fails with --workers=1 in CI.

See report generated by Claude Code: https://github.com/YuriiMotov/playwright-1.62-new-tab-mre/blob/master/README.md

Environment

System:
    OS: Linux 7.0 Ubuntu 24.04.4 LTS 24.04.4 LTS (Noble Numbat)
    CPU: (14) x64 Intel(R) Core(TM) Ultra 5 125U
    Memory: 28.49 GB / 46.52 GB
    Container: Yes
  Binaries:
    Node: 22.23.0 - /run/user/1000/fnm_multishells/1402339_1785955498713/bin/node
    npm: 10.9.8 - /run/user/1000/fnm_multishells/1402339_1785955498713/bin/npm
    bun: 1.3.8 - /home/yurii/.bun/bin/bun
  IDEs:
    VSCode: 1.124.2 - /usr/bin/code
  Languages:
    Bash: 5.2.21 - /usr/bin/bash
  npmPackages:
    @playwright/test: 1.62.1 => 1.62.1

[Mahnoor-Zaffar]

Hey! Thanks for reporting this.

The most likely root cause of this issue appears to be related to changes made in version 1.62.0 that affect the handling of new tab openings. While the specific code changes are not detailed in the issue, the problem is isolated to the functionality that manages new tab interactions. The affected code may reside in the page.ts file or related modules that handle browser interactions.

A reasonable direction for fixing this issue would be to investigate the changes made in version 1.62.0 that relate to tab management and ensure that the logic for handling middle and modifier clicks is functioning as intended.

If no one is currently working on this, I'd be happy to take a look and put together a fix.

[github-actions]

Thanks for the exceptionally clean MRE — the version table and the "no JavaScript, pure browser default action" framing made this easy to confirm.

Reproduced on 1.62.1, and it looks already fixed on tip-of-tree.

What I ran:

• 1.62.1 — your MRE unchanged, --repeat-each=25 --workers=16 on a 4-core box (heavy oversubscription): 2/50 failed with waitForURL: Test timeout of 30000ms exceeded. Matches your report.
• tip-of-tree (1.63.0-next) — the same scenario condensed to a self-contained spec (middle-click and ControlOrMeta click, plain <a href>, context.waitForEvent('page') + waitForURL): 0 failures across 50 tests @ 16 workers and 100 tests @ 32 workers (8× oversubscription). Could not get it to fail.

Both runs use the same default headless-shell binary, so it's an apples-to-apples comparison.

The relevant difference is the bundled browser: 1.62.x ships Chromium chromium-1234, tip-of-tree ships chromium-1237. This is a browser-default-action bug (opening a background tab with nothing in the page to interfere), and it disappears with the newer Chromium roll — consistent with an upstream fix that came in after 1.62.x was cut.

So: nothing to change in the Playwright test code — the intermittent "new tab never opens / never navigates" behavior is gone on the current Chromium. It should ride out with the next release that carries chromium-1237. If you can, giving @playwright/test@next a spin against your real app would be a useful confirmation from your side.

_{Triaged by the Playwright bot - agent run}

[YuriiMotov]

I've just tested it with 1.63.0-alpha-2026-08-06 and it still fails:

$ npm i -D @playwright/test@next

changed 3 packages, and audited 4 packages in 35s
found 0 vulnerabilities

$ npx playwright install

Downloading Chrome for Testing 152.0.7977.8 (playwright chromium v1237) from https://cdn.playwright.dev/builds/cft/152.0.7977.8/linux64/chrome-linux64.zip
184.7 MiB [====================] 100% 0.0s
Chrome for Testing 152.0.7977.8 (playwright chromium v1237) downloaded to ...
...

$ npx playwright --version

Version 1.63.0-alpha-2026-08-06

$ npx playwright test --repeat-each=25 --workers=16

...
  2 failed
    [chromium] › tests/new-tab.spec.ts:3:5 › middle click opens a new tab ──────────────────────────
    [chromium] › tests/new-tab.spec.ts:3:5 › middle click opens a new tab ──────────────────────────
  48 passed (33.5s)

npx envinfo --preset playwright

  System:
    OS: Linux 7.0 Ubuntu 24.04.4 LTS 24.04.4 LTS (Noble Numbat)
    CPU: (14) x64 Intel(R) Core(TM) Ultra 5 125U
    Memory: 29.22 GB / 46.52 GB
    Container: Yes
  Binaries:
    Node: 22.23.0 - /run/user/1000/fnm_multishells/308728_1786008511663/bin/node
    npm: 10.9.8 - /run/user/1000/fnm_multishells/308728_1786008511663/bin/npm
    bun: 1.3.8 - /home/yurii/.bun/bin/bun
  IDEs:
    VSCode: 1.124.2 - /usr/bin/code
  Languages:
    Bash: 5.2.21 - /usr/bin/bash
  npmPackages:
    @playwright/test: ^1.63.0-alpha-2026-08-06 => 1.63.0-alpha-2026-08-06 

[github-actions]

Hi, I'm the Playwright bot and I took another look — thanks for coming back with the @next numbers.

This is a live regression, still present on tip-of-tree. I can confirm it, and I'm correcting the earlier triage on this thread: it is not fixed by the newer Chromium roll. Clean on 1.61.1, broken from 1.62.0 onward, and still broken on 1.63.0-alpha with chromium-1237.

What I ran (your MRE, unchanged, on a 4-core box — heavy oversubscription at 16 workers)

@playwright/test	Chromium	Result
1.61.1	headless-shell v1228	0 / 300 failed (3× --repeat-each=50)
1.62.1	headless-shell v1234	2 / 50 failed (--repeat-each=25)
1.63.0-alpha (@next)	headless-shell v1237	8 / 300 failed (3× --repeat-each=50)

Failure is the one you reported — browserContext.waitForEvent('page') / waitForURL hangs until the 30s deadline; the background tab either never opens or never navigates. It's timing-dependent, so a single 50-test run often passes clean — it takes repetition under load to surface, which is why the earlier "0 failures on ToT" run was misleading.

Command: PLAYWRIGHT_HTML_OPEN=never npx playwright test --repeat-each=50 --workers=16

Condensed self-contained repro

Same trigger as your MRE, boiled down to our fixtures (still needs load/parallelism to surface — one run passes):

test('middle click opens a background tab', {
  annotation: { type: 'issue', description: 'https://github.com/microsoft/playwright/issues/42142' }
}, async ({ page, context, server }) => {
  server.setRoute('/', (req, res) => {
    res.writeHead(200, { 'content-type': 'text/html' });
    res.end('<a href="/target.html">Open target</a>');
  });
  server.setRoute('/target.html', (req, res) => {
    res.writeHead(200, { 'content-type': 'text/html' });
    res.end('<h1>Target</h1>');
  });
  await page.goto(server.PREFIX + '/');
  const popupPromise = context.waitForEvent('page');
  await page.getByRole('link', { name: 'Open target' }).click({ button: 'middle' });
  await (await popupPromise).waitForURL('**/target.html');
});

Since 1.61.1 never fails across the full range you tried and the break lands squarely on 1.62.0, this looks like a real regression on our side that the Chromium update didn't touch. I'm a first pass, so I've left the root cause for a maintainer rather than guessing — but the boundary is clear and the repro is solid.

_{Triaged by the Playwright bot.}

_{Triaged by the Playwright bot - agent run}

[alirezaedalat]

Hi, I’d like to investigate this regression.

My plan is to reproduce it using the provided repository, compare the behavior
between 1.61.1 and 1.62.x, and identify whether the failure is related to input
dispatch, modifier handling, or new-page event synchronization.

If I can isolate the regression, I’ll add a focused regression test and propose
a minimal fix.

Please let me know if someone is already working on this.

Thanks.