fix(browser): pin named browser_exec sessions to their own tab on shared browsers - #86924
Merged
Merged
Conversation
Follow-up to #86916. That fix gave named sessions their own daemon (socket/log/pid) and their own provider browser — but on a SHARED local Chrome / CDP browser, a fresh named daemon still attaches to the first existing page, the same page a sibling daemon may hold. A named session that never calls new_tab() could still stomp another's tab. browser_exec now prepends a small preamble to the model's code for named sessions on shared browsers: once per daemon process (marker keyed by uid + BU_NAME + daemon pid), it creates a fresh tab via Target.createTarget and switch_tab()s onto it before any model code runs. Private per-name browsers (provider-keyed bu-named-<name>, or direct-API Browser Use cloud) skip the preamble via an internal env sentinel popped before launch — there's nobody to collide with, and the extra tab would leak. Best-effort by design: if the preamble's CDP calls fail, behavior degrades to pre-fix, never blocks the exec. E2E against a shared headless Chrome with the STOCK harness: two named sessions issuing bare js() writes (no new_tab) kept distinct state (EDGE-A/EDGE-B read back intact); the sabotage run without the preamble reproduced the clobber (both read EDGE-B). Removes the dependency on the upstream browser-harness tab-isolation PR for correctness.
Contributor
૮ >ﻌ< ა ci reviewran on 7641f28 — fix(browser): pin named sessions to their own tab on shared
|
alt-glitch
added
type/bug
Collaborator
7 tasks
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
2 participants
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
Named
browser_execsessions on a shared browser (local Chrome //browser connectCDP) now pin themselves to a tab they created before any model code runs — closing the last clobber window left after #86916 and removing any dependence on the upstream browser-harness tab-isolation PR (browser-use/browser-harness#616).Root cause of the residue: a fresh named daemon attaches to the first existing page of the shared browser, the same page a sibling daemon may hold. A named session that only issued
js()/goto_urlwithout ever callingnew_tab()could still stomp another session's tab.Changes
tools/browser_use_cli.py:_OWN_TAB_PREAMBLEprepended to model code for named sessions on shared browsers — once per daemon process (marker keyed uid + BU_NAME + daemon pid, so daemon restarts re-pin but mid-session tab switches are untouched), itTarget.createTargets a fresh tab andswitch_tab()s onto it. Best-effort: CDP failure degrades to pre-fix behavior, never blocks the exec._resolve_backend_cdpmarks provider-keyedbu-named-*browsers and direct-API BU cloud; sentinel is popped before subprocess launch, never exported).Validation
tests/tools/test_browser_use_cli.pyjs()writes (nonew_tab)Infographic