Skip to content

fix(chromium): do not hang connectOverCDP on a page stuck loading#41128

Open
yury-s wants to merge 5 commits into
microsoft:mainfrom
yury-s:fix-41093
Open

fix(chromium): do not hang connectOverCDP on a page stuck loading#41128
yury-s wants to merge 5 commits into
microsoft:mainfrom
yury-s:fix-41093

Conversation

@yury-s
Copy link
Copy Markdown
Member

@yury-s yury-s commented Jun 3, 2026

Summary

  • connectOverCDP hung forever when a pre-existing tab's first navigation never committed (e.g. a tab stuck behind a hung proxy, which Edge 148's online new-tab page made easy to hit): the page stayed on the initial empty document and the connection blocked waiting for a navigation that never arrived.
  • Targets that already existed when we attach during connect are now reported as-is instead of blocking on their first navigation commit.

Fixes #41093

yury-s added 3 commits June 3, 2026 12:29
When connecting over CDP, a pre-existing tab whose first navigation never
commits (e.g. stuck behind a hung proxy) left the page on the initial empty
document forever, blocking the connection while it waited for a navigation
that never arrived. Report such pre-existing pages as-is instead.

Fixes: microsoft#41093
Verify connectOverCDP surfaces both pages and that releasing the held
response lets the previously-stuck tab finish navigating to its URL.
@github-actions

This comment has been minimized.

@github-actions

This comment has been minimized.

@github-actions

This comment has been minimized.

}),
browser._defaultContext.initialize(),
]);
browser._attachingPreExistingTargets = false;
Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Perhaps we should not wait for all pages to be initialized instead?

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't think we can, it will lead to unpredictable page list for the context right after connect.

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

trying to not wait for the pages which are on the initial page and we are in connectOverCDP mode

@github-actions

This comment has been minimized.

Comment thread tests/library/chromium/connect-over-cdp.spec.ts
Per review feedback, rather than reporting a stuck pre-existing page early,
do not wait for all pages to be initialized when connecting over CDP. A tab
stuck loading no longer blocks the connection; pages are reported as they
initialize. Existing tests that read pages right after connect now wait for
them to appear.
@github-actions

This comment has been minimized.

@github-actions

This comment has been minimized.

Rather than skipping the page-initialization wait entirely, parametrize it:
when connecting over CDP, still wait for pages that have committed a
navigation, but not for pages stuck on the initial empty document (their
first navigation may never commit). This keeps the page list available right
after connect for normal pages, while not hanging on a stuck tab.
@yury-s yury-s requested review from dgozman and pavelfeldman June 4, 2026 18:21
@github-actions
Copy link
Copy Markdown
Contributor

github-actions Bot commented Jun 4, 2026

Test results for "MCP"

7230 passed, 1103 skipped


Merge workflow run.

@github-actions
Copy link
Copy Markdown
Contributor

github-actions Bot commented Jun 4, 2026

Test results for "tests 1"

1 failed
❌ [playwright-test] › golden.spec.ts:66 › should generate default name @macos-latest-node20

2 flaky ⚠️ [chromium-library] › library/video.spec.ts:275 › screencast › should capture navigation `@chromium-ubuntu-22.04-node24`
⚠️ [firefox-library] › library/inspector/cli-codegen-3.spec.ts:224 › cli codegen › should generate frame locators (4) `@firefox-ubuntu-22.04-node20`

39546 passed, 771 skipped


Merge workflow run.

// The stuck tab has not committed a navigation yet, so it is not reported. Releasing the
// response lets it finish navigating to /hang and show up in the context.
releaseHang();
await expect.poll(() => context.pages().map(page => page.url())).toContain(server.PREFIX + '/hang');
Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can just const page = await context.waitForEvent('page').


// connectOverCDP must not hang waiting for the stuck page to commit a navigation.
const cdpBrowser = await browserType.connectOverCDP(`http://127.0.0.1:${port}/`);
const context = cdpBrowser.contexts()[0];
Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

expect there is just a single about:blank page?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

[Bug]: connect_over_cdp() hangs after <ws connected> with Microsoft Edge 148 on Windows

3 participants