[Bug]: connectOverCDP still hangs when an existing page's renderer is alive but busy (follow-up to #42936) #44052

Activity

1. Yury Semikhatsky (yury-s)

   added

   agent-triage

   on Nov 11, 2026
2. microsoft-playwright-automation commented on Nov 11, 2026

   

   microsoft-playwright-automationBot

   on Nov 11, 2026 – with microsoft/playwright-automation · Hidden as outdated

   show commentMore actions
3. microsoft-playwright-automation commented on Nov 11, 2026

   

   microsoft-playwright-automationBot

   on Nov 11, 2026 – with microsoft/playwright-automation

   Contributor

   More actions

   Hi, I'm the Playwright bot. I reproduced this and checked an early-return change.

   Reproduced on current main (1.66.0-next, 3b438229c6a2ccdbe2d3572755935892203d83c3), Chromium 158.0.8127.18 on macOS, headed and headless. A busy renderer still blocks attachment; noDefaults does not help. This case is not fixed by #42936.

   I have not proposed a fix. Returning early changes which existing pages are available after connection, and simply bounding the wait loses context updates: in an experiment, an init script added after connection never reached the delayed page, even after it recovered and navigated again. This needs an explicit partial-readiness API policy, rather than a timeout around the existing wait. I recommend an opt-in mode that preserves today's complete initial page list by default and reconciles context updates before exposing delayed pages. The compatibility concern was also recorded in the review of #41128.

   Reproduction and results

   This fixture-based test fails at connectOverCDP, after the WebSocket connects. The console event confirms that the loop has started, without a timing guess.

   test('attach while an existing renderer is busy', {
     annotation: {
       type: 'issue',
       description: 'https://github.com/microsoft/playwright/issues/44052',
     },
   }, async ({ browserType, launchPersistent, server }, testInfo) => {
     test.fail(true, 'Current connection waits for every existing page.');
     const port = 9339 + testInfo.workerIndex;
     const { context, page } = await launchPersistent({
       args: [`--remote-debugging-port=${port}`, '--site-per-process'],
     });
     await page.goto(server.EMPTY_PAGE);
     const healthy = await context.newPage();
     await healthy.goto(server.CROSS_PROCESS_PREFIX + '/title.html');
     const started = page.waitForEvent('console', m => m.text() === 'busy');
     void page.evaluate(() => {
       console.log('busy');
       for (;;) {}
     }).catch(() => {});
     await started;
     const connected = await browserType.connectOverCDP(
       `http://127.0.0.1:${port}`, { timeout: 2000 });
     expect(await connected.contexts()[0].pages()[0].title()).toBe('Woof-Woof');
     await connected.close();
   });

   Case	Headless	Headed
   Six-second loop, 1-second connection timeout, with and without noDefaults	Both time out	Both time out
   Connect again during that finite loop with a 10-second timeout	Connects when loop ends, about 6 seconds after loop start; both pages present	Same
   Endless loop, 1-second connection timeout, with and without noDefaults	Both time out	Both time out
   Healthy page in another renderer during failed connection attempts	Title remains readable	Same
   HTTP /json/version during finite-loop connection failures	Responds	Responds
   Desired early attachment, 2-second timeout	Fails with TimeoutError	Same

   Additional checks on unchanged main:

   • Existing crashed-page, crashed-opener and complete-page-list tests pass.
   • The discarded-page test timed out in the first grouped run; an isolated rerun with API logging passed, including attachment after discard.
   • Context init-script propagation after a finite busy period passes.

   The temporary early-return experiment raced initialization against 500 ms. It returned only the healthy page. After context.addInitScript('window.connectionMarker = "installed"'), the busy page eventually appeared, but the marker remained undefined after navigation. Without that experiment, the marker was "installed". The experimental source change was reverted.

   Commands used: npm run build; npm run ctest -- tests/library/chromium/connect-over-cdp-busy.spec.ts --workers=1 --retries=0 --reporter=line (also --headed); the context-init-script case separately on main and the experiment; and connect-over-cdp.spec.ts --grep 'CD-00[234]|CD-017', with CD-004 rerun under DEBUG=pw:api.

   Only current main was tested, not the reported 1.65.0 package. Firefox and WebKit do not support connectOverCDP, so they are not applicable. No public API or default behavior was changed.

   _{Triaged on macOS by the Playwright bot - agent run}
4. vaidehi-snk commented on Nov 11, 2026

   

   Vaidehi Kakad (vaidehi-snk)

   on Nov 11, 2026

   More actions

   I’d like to work on this issue if community contributions are welcome. The busy-renderer repro is clear, and I’ll make sure any fix keeps healthy pages connectable while preserving the existing page initialization and context-update behavior. Could a maintainer confirm the approach and assign the issue to me before I start?