Dispatch start_url navigation asynchronously in chromium configure#287
Draft
yummybomb wants to merge 1 commit into
Draft
Dispatch start_url navigation asynchronously in chromium configure#287yummybomb wants to merge 1 commit into
yummybomb wants to merge 1 commit into
Conversation
The configure handler blocked its response on the start_url navigation dispatch (CDP dial + Page.navigate, up to 3s on a slow dial). Kick it in a goroutine instead: it still runs after profile install and chromium restart, so ordering relative to profile loading is unchanged, but the caller (the API's synchronous ConfigureAndClaimActivity) no longer waits on it. Navigation was already best-effort — failures only logged.
yummybomb
force-pushed
the
hypeship/async-start-url-nav
branch
from
c6d45f0 to
20b4e7b
Compare
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
1 participant
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.
Summary
The batched configure handler blocks its response on the start_url navigation dispatch — a CDP dial +
Page.navigatebounded by the 3sstartURLDispatchTimeout. For sessions created with configuration (profile, viewport, extensions, …), the API awaits this handler synchronously insideConfigureAndClaimActivity, so that dispatch time sits directly onPOST /browserslatency.This moves the navigation dispatch into a goroutine (same
context.WithoutCancelpattern the handler already uses for recording restarts), kicked at the earliest safe point: after profile install and the chromium restart in the stop/start path (a restart would undo the navigation), and after the display patch in the display-only path. Navigation was already best-effort — errors are only logged — so the response contract is unchanged.Companion to kernel/kernel#2380, which takes start_url-only creates off the synchronous claim path entirely.
Semantics
start_urlowns the initial tab state: when the dispatch lands it closes all other page targets and navigates the survivor to the given URL — including tabs restored by a chrome profile. This is intentional. With the dispatch now async, the navigation lands shortly after the configure response instead of strictly before it, so a client that connects and starts driving immediately can have that work reset when the dispatch lands (measured locally: a navigation issued 11ms after the response was overridden ~120ms later; 500ms after was untouched). Clients passingstart_urlshould treat the page as not theirs until the start URL is loaded.Test plan
go build ./cmd/api/.../go test ./cmd/api/api/ -run Configure🤖 Generated with Claude Code