fix(chromium): do not hang connectOverCDP on a page stuck loading#41128
fix(chromium): do not hang connectOverCDP on a page stuck loading#41128yury-s wants to merge 5 commits into
Conversation
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.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
| }), | ||
| browser._defaultContext.initialize(), | ||
| ]); | ||
| browser._attachingPreExistingTargets = false; |
There was a problem hiding this comment.
Perhaps we should not wait for all pages to be initialized instead?
There was a problem hiding this comment.
I don't think we can, it will lead to unpredictable page list for the context right after connect.
There was a problem hiding this comment.
trying to not wait for the pages which are on the initial page and we are in connectOverCDP mode
This comment has been minimized.
This comment has been minimized.
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.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
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.
Test results for "MCP"7230 passed, 1103 skipped Merge workflow run. |
Test results for "tests 1"1 failed 2 flaky39546 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'); |
There was a problem hiding this comment.
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]; |
There was a problem hiding this comment.
expect there is just a single about:blank page?
Summary
connectOverCDPhung 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.Fixes #41093