[docs] decision: browsing contexts are exposed as handle objects#17681
Open
AutomatedTester wants to merge 1 commit into
Open
[docs] decision: browsing contexts are exposed as handle objects#17681AutomatedTester wants to merge 1 commit into
AutomatedTester wants to merge 1 commit into
Conversation
7a177ac to
6b5f6f8
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
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.
💥 What does this PR do?
Proposes a design decision record: browsing contexts are exposed as handle objects.
Working with multiple tabs/windows over BiDi is awkward because there is no object representing a single browsing context — every operation is called on one shared module instance and takes the context id explicitly (
browsing_context.navigate(context=id, ...)). For parallel work this means each worker repeatscontext=bookkeeping against shared state, with no per-tab unit to own. This record proposes a per-context handle object (returned bycreate/get_tree/expect_page) that carries the per-context operations as methods and scopes events to that context — matching the Playwright model where operations live on the object, which is exactly what makes one-context-per-worker parallelism clean. The flat module API stays as the compatibility surface.🔧 Implementation Notes
docs/decisions/process from [docs] add design decision record process and template #17665 — depends on [docs] add design decision record process and template #17665 landing (adds onlydocs/decisions/0008-*.md).expect_*primitive ([docs] decision: BiDi events are awaited with expect_* context managers #17671) forexpect_page/expect_popup.BrowserContext), and fixing per-context event-subscription scoping.Pagemodel is explicitly out of scope (its own RFC). No wire-protocol change.🤖 AI assistance
browsing_contextsurface and BiDi transport against Playwright's object/concurrency model; revised through discussion and review💡 Additional Considerations
Extends the set of BiDi ergonomics decision records (#17671–#17677) with the parallelisation/object-model concept. The cross-binding name of the handle (
Page-like /Tab/BrowsingContextHandle) is part of what's being decided. Cross-binding convergence is tracked in the binding-status table.🔄 Types of changes