[Bug]: `page.goto(`chrome://extensions`)` crashes browser

[Skn0tt]

Version

478b9f0

Steps to reproduce

test('repro', async ({ page }) => {
  await page.goto(`chrome://extensions`);
});

Expected behavior

unsure.

Actual behavior

npm run ctest: Call rejects with net::ERR_INVALID_URL, chrome survives.
npm run ctest --headed: Sometimes passes, sometimes rejects with page.goto: Target page, context or browser has been closed.. Chrome crashes.

PWTEST_CHANNEL=chromium npm run ctest: Call rejects with Target page, context or browser has been closed, then browser crashes.
PWTEST_CHANNEL=chromium npm run ctest --headed: Call passes, then browser crashes.

PWTEST_CHANNEL=chrome npm run ctest: Call rejects with Target page, context or browser has been closed, then browser crashes.
PWTEST_CHANNEL=chrome npm run ctest --headed: Sometimes passes, sometimes rejects with `page.goto: Target page, context or browser has been closed. In both cases, chrome crashes afterwards.

PWTEST_CHANNEL=msedge npm run ctest + --headed: Passes.
npm run ftest + --headed: Rejects with NS_ERROR_FAILURE.
npm run wtest + --headed: Rejects with Protocol error (Playwright.navigate): Navigation cancelled.

crash.txt

Additional context

No response

Environment

Simon's Mac.

[krishpranav]

hi, i would like to work on this issue.

[krishpranav]

I looked into this. The crash is upstream in Chromium, and it is narrower than "chrome:// URLs" — it is specifically navigating inside a CDP-created off-the-record browser context, which is what every non-persistent context is.

What reproduces it

Tested on chromium-1234 (151.0.7922.34), macOS arm64:

Setup	Result
Plain Chrome, regular profile	works
Plain Chrome, real incognito (--incognito)	works
Plain Chrome + all 41 Playwright launch switches, no CDP	works
launchPersistentContext (default profile)	works — 200, title "Extensions"
connectOverCDP + default-profile tab	works
Target.createBrowserContext + Page.navigate, raw CDP, no Playwright	browser-process SIGSEGV

The last row is the interesting one — a bare websocket script with none of Playwright's switches crashes the browser identically:

const bc  = (await send('Target.createBrowserContext', {})).result.browserContextId;
const tid = (await send('Target.createTarget', { url: 'about:blank', browserContextId: bc })).result.targetId;
const sid = (await send('Target.attachToTarget', { targetId: tid, flatten: true })).result.sessionId;
await send('Page.navigate', { url: 'chrome://settings' }, sid);  // socket dies, no response

So --disable-extensions and the rest of the switch list are not involved; I verified that separately.

Why those particular pages

The affected set lines up exactly with the WebUIs Chromium disallows in incognito (IsURLAllowedInIncognito). Those get redirected to a normal window in the original profile, and that redirect path null-derefs when the profile came from CDP — matching the KERN_INVALID_ADDRESS at 0x30 in the attached crash log.

Measured headed, isolated context:

• crashes: settings, extensions, history, password-manager, help, apps
• loads (200): version, gpu, flags, bookmarks, downloads, net-export, management, sync-internals, print, policy, profile-internals, about, bookmarks-side-panel.top-chrome

Headless is different again: no chrome:// page is available there, every one fails with net::ERR_INVALID_URL, which is why the original report saw that error in ctest but a crash in ctest --headed.

On the proposed fix

Nothing on the Playwright side can make these pages load in an isolated context. What it can do is stop handing Chromium a navigation known to kill the browser — losing the browser process takes down every other page in the session, whereas a rejected goto does not. I have a PR that refuses exactly those six hosts in non-persistent contexts, with a message pointing at launchPersistentContext() (which works today).

Two limits worth stating plainly:

• It guards the page.goto path only. A click or window.location inside the page still reaches Chromium directly and will still crash.
• The reporter noted msedge passes. I could not verify that locally (Edge is not installed here), so the guard currently applies to the whole Chromium family. Happy to scope it by channel if you would rather not block a case that genuinely works on Edge.

Also note this issue is assigned to @dgozman if the intended direction is different (e.g. upstream-only, or a documenting test rather than a guard), say so and I will drop or rework the PR.