Repository navigation
Conversation
…cked reads On Windows, alert() under the default auto-dialog handling wedged the tab: the auto-dismiss task read dialog-opening events from the shared broadcast receiver, which can lag and drop the opening event. A dropped event meant the dialog was never dismissed, so the triggering command and every later command timed out after ~30 s with os error 10060 until close reported page_wedged. `dialog status` also reported no dialog, since auto-handled dialogs were never tracked. Listen for Page.javascriptDialogOpening on a lossless method tap instead of the shared broadcast, and track every dialog in pending_dialog, including the ones the background task auto-dismisses. The dismiss usually lands first and the closed event clears the tracking on the next drain; but if the dismiss is missed or fails, the dialog stays visible to `dialog status`, the fail-fast gate, and the timeout path, so an open alert no longer looks like a wedged tab. Also fail fast for `url` and `title` while a dialog is open: both evaluate JavaScript in the page, so they hung until the client read timeout instead of reporting the blocking dialog. `dialog`, `screenshot`, and tab management stay usable during a dialog. Fixes vercel-labs#2511
Contributor
|
@sx4im is attempting to deploy a commit to the Vercel Labs Team on Vercel. A member of the Team first needs to authorize it. |
Vercel review on vercel-labs#2528 found two issues in the dialog tracking: 1. If broadcast lag dropped an auto-dismissed alert's close event after its opening was drained, pending_dialog stayed set forever and page commands kept failing fast on a dialog that no longer exists. The background task saw the same opening on its lossless tap and already dismissed it, so on lag the tracked alert/beforeunload entry is stale: clear it. Confirm/prompt dialogs are never auto-dismissed, so their entries stay tracked. 2. The dialog-drain unit test always panicked: the drain's session filter discarded dialog events with no browser attached. Dialog open/close is daemon-global state, so dialog events bypass the session filter (the fail-fast gate still scopes to the active tab), and a close only clears the dialog it closed.
Vercel review on vercel-labs#2528 (comment 4523632585): tracking a background-tab dialog without updating dialog resolution made `dialog accept` and `dialog dismiss` target the active tab instead of the reported dialog. BrowserManager::handle_dialog always used the active session. It now takes the tracked dialog's session (falling back to the active session when none is recorded, e.g. a top-level page dialog), and the CLI `dialog` handler passes pending_dialog's session_id. The fail-fast gate already scoped blocking to the active tab; only the resolution path was still active-tab bound. New mock-CDP unit test pins both halves: a background-tab dialog is answered on its own session, and a missing session falls back to the active tab.
This branch has not been deployed
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Fixes #2511
On Windows, calling alert() under the default auto-dialog handling wedged the tab: the auto-dismiss task read dialog-opening events from the shared broadcast receiver, which can lag and drop the opening event. A dropped event meant the dialog was never dismissed, so the triggering command and every later command timed out after about 30 seconds with os error 10060 until close reported page_wedged.
What changed:
How verified: