playwright-cli attach hangs forever: Tab.headerSnapshot awaits page.title() without a timeout on a half-initialised page #489

Activity

1. dgozman commented on Oct 26, 2026

   

   Dmitry Gozman (dgozman)

   on Oct 26, 2026

   Contributor

   More actions

   cyppe Any chance you can dump the contents of chrome://discards and chrome://process-internals (all three tabs there) next time this happens? We really need to figure out what's the state of the page that prevents attach from completing, to figure out a long-term solution.
2. Pavel Feldman (pavelfeldman)

   added

   needs-triage

   on Oct 31, 2026
3. github-actions commented on Oct 31, 2026

   

   github-actionsBot

   on Oct 31, 2026 – with GitHub Actions · Hidden as outdated

   show commentMore actions
4. github-actions commented on Oct 31, 2026

   

   github-actionsBot

   on Oct 31, 2026 – with GitHub Actions

   More actions

   Hi, I'm the Playwright bot. I tried to reproduce this on Linux.

   I could not recreate the half-initialized frame, on current main or with playwright-core 1.64.1. With 28 tabs, background reloads and frozen tabs, attachment and later commands completed. A coverage test for attachment after a background-tab reload is proposed; it does not fix or simulate the reported missing execution context.

   One relevant detail: page.title() evaluates in Playwright's utility world, not the default world used by bare CDP Runtime.evaluate. A successful default-world evaluation does not establish that the utility-world context was initialized. The timeout patch in microsoft/playwright#43620 was closed without merging, so I have not repeated it.

   Could you share a sanitized DEBUG=pw:protocol,pw:channel log starting before the failing attach, together with the chrome://discards and chrome://process-internals dumps requested above? The missing piece is a way to create, or inspect initialization of, the affected frame.

   What I ran

   All runs were on Linux. Each probe used 28 tabs and checked all titles after CDP connection, with a five-second bound on title collection. Variations were ordinary loaded tabs, a frozen background tab, reload while frozen, thawing that tab, and 20 reload/connection races.

   CLI/core	Browser	Mode	Result
   Upstream 1.65.0-next, a6fb02f5aa494764a21a637f2db6ea1031461935	Chromium 158.0.8127.2	Headless and headed	All title probes completed
   Same upstream commit	Chrome 156.0.8078.47	Headed	All title probes completed, both with the original Playwright sessions attached and after detaching them
   CLI 0.1.22, pinned core 1.64.0-alpha-1790635538000, upstream e8149b8257d32dcf8f72573ecc43e72439da7080	Chromium 155.0.8059.12	Headed	All title probes completed
   CLI 0.1.22, core 1.64.1, upstream cfe490d941f992655948eee8fd4fd94e1c4234bf	Chrome 156.0.8078.47	Headed	All title probes completed

   For upstream Chrome, the pinned core, and core 1.64.1, I also disabled the original session's focus emulation and confirmed document.hidden === true on the background tab before testing. In the four non-race states, actual CLI attach, tab-list, and run-code 'async page => 1' all completed and returned the expected titles/result. No probe produced the reported empty-URL frame.

   The reporter's Chromium 154 and long-running browser profile were not available. These results do not establish that the bug is fixed.

   The existing attach via cdp test now includes the background reload and checks attachment metadata, a snapshot, and a later run-code result. cli-cdp.spec.ts and cli-endpoint.spec.ts passed across the Chrome, Chromium, Firefox, and WebKit projects: 42 passed, 14 skipped. CDP-only cases are skipped for Firefox and WebKit. Build and the full npm run flint check passed.

   Condensed scenario covered by the proposal

   Using the repository's cdpServer, cli, and server fixtures:

   const context = await cdpServer.start();
   const [page] = context.pages();
   await page.goto(server.HELLO_WORLD);
   const backgroundPage = await context.newPage();
   await backgroundPage.goto(server.PREFIX + '/title.html');
   await page.bringToFront();
   await backgroundPage.reload();
   
   const attached = await cli('attach', `--cdp=${cdpServer.endpoint}`);
   expect(attached.exitCode).toBe(0);
   expect(attached.output).toContain(`[Woof-Woof](${server.PREFIX}/title.html)`);
   const result = await cli('run-code', 'async page => 1');
   expect(result.output).toContain('### Result\n1');

   This passes today. It covers the background-reload setup, not the unknown trigger that leaves a frame without an execution context.

   Draft PR: microsoft/playwright#43816

   _{Triaged on Linux by the Playwright bot - agent run}