[docs] Selenium 5 release charter#17717
Open
titusfortner wants to merge 1 commit into
Open
Conversation
Contributor
PR Summary by QodoDocument Selenium 5 release charter and formalize ADR tracking workflow Description
Diagram
High-Level Assessment
Files changed (5)
|
Contributor
Code Review by Qodo
Context used✅ Tickets:
🎫 [🚀 Feature]: Implement Navigation Commands with BiDi 🎫 [🚀 Feature]: Implement high level BiDi script commands 🎫 [🚀 Feature]: Implement high level BiDi network commands +3 more✅ Compliance rules (platform):
11 rules 1.
|
titusfortner
force-pushed
the
c/modest-benz-4f2db6
branch
from
f5acd6e to
de97f5f
Compare
![qodo-code-review[bot]](https://avatars.githubusercontent.com/in/484649?s=60&v=4){kind=small}
Comment on lines
+20
to
+47
| ## Required for release | ||
|
|
||
| ### BiDi support boundary — _ADR pending_ | ||
|
|
||
| How the WebDriver BiDi protocol is exposed to users across the bindings. The ADR sets where the | ||
| boundary sits between supported Selenium API and internal implementation, and how each binding | ||
| marks it. | ||
|
|
||
| ### Classic fallback for BiDi-backed commands — _ADR pending_ | ||
|
|
||
| A defined, cross-binding mechanism for running a supported command over BiDi and falling back to | ||
| Classic when BiDi or the browser does not support it. The mechanism is required; migrating every | ||
| command is not. | ||
|
|
||
| ### Network async/event API — _ADR pending_ | ||
|
|
||
| The cross-binding API for adding, removing, and clearing handlers for requests, responses, and | ||
| authentication. | ||
|
|
||
| ### Script and logging async/event API — _ADR pending_ | ||
|
|
||
| The cross-binding API for pinned scripts (pin / unpin / execute) and for console-message, | ||
| JavaScript-error, and DOM-mutation handlers. | ||
|
|
||
| ### Selenium Manager finalized API — _ADR pending_ | ||
|
|
||
| A finalized, documented API the bindings invoke, versioned independently of the client. | ||
|
|
Contributor
There was a problem hiding this comment.
2. Missing bidi navigation requirement 📎 Requirement gap ≡ Correctness
The charter's "Required for release" list omits BiDi navigation commands and pageLoadStrategy-aware waiting. This fails to reflect the compliance requirement that BiDi-based navigation be implemented across bindings with page load strategy respected.
Agent Prompt
## Issue description
The Selenium 5 release charter does not list BiDi-based navigation (with pageLoadStrategy-aware waiting) as a required-for-release item, even though the compliance checklist mandates it as a minimum viable BiDi module across bindings.
## Issue Context
This document is positioned as the definitive list of decisions/features required for Selenium 5. If navigation is required for release, it should be explicitly listed and tied to the ADR/design work.
## Fix Focus Areas
- docs/plans/selenium-5.md[20-47]
ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools
Member
Author
There was a problem hiding this comment.
The intent was to make this part of the ADR for "Classic fallback for BiDi-backed commands" since it is kind of an implementation detail. But agreed, especially if we are going to move that bullet to out of scope (not a requirement for Selenium 5) we need to decide separately if we want to define the mechanism for deciding BiDi vs Classic path for sessions and implement something like Navigation, which Ruby already does.
Contributor
|
Code review by qodo was updated up to the latest commit de97f5f |
AutomatedTester
approved these changes
Jun 25, 2026
titusfortner
commented
Jun 25, 2026
| boundary sits between supported Selenium API and internal implementation, and how each binding | ||
| marks it. | ||
|
|
||
| ### Classic fallback for BiDi-backed commands — _ADR pending_ |
Member
Author
There was a problem hiding this comment.
- This is too specific of subject. It should be "Partial BiDi implementation support" where we decide what it means to support a remote end that doesn't implement every feature.
- One specific issue with the "per command" fallback is that not all commands can switch between classic and bidi depending on what previous commands were sent
- This issue is not just about "what if Safaridriver implements BiDi support but not for everything at first" it can also be about supporting older browsers with inicomplete BiDi implementations
The consensus at the 6/25 TLC meeting was that this probably doesn't belong as a blocker or a prerequisite for Selenium 5, and it can be part of the ADR for the Classic Migration.
diemol
reviewed
Jun 25, 2026
| boundary sits between supported Selenium API and internal implementation, and how each binding | ||
| marks it. | ||
|
|
||
| ### Classic fallback for BiDi-backed commands — _ADR pending_ |
Member
There was a problem hiding this comment.
This could be an implementation detail of the migration to Selenium 5 ADR.
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
4 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.
📄 This body is the context: why we need it, the required decisions, and the possible additions to consider.
Why we need this
We have dozens of ADR PRs in flight, and many assume different answers to "what is Selenium 5."
Binding-level efforts in .NET and Python are each moving on their own reading of the goal. We need
one agreed boundary for what blocks the release before arguing implementation details. This
charter is that boundary; the cross-binding mechanics are left to the ADRs it lists.
How the scope has moved
classic method with BiDi, each with a Classic fallback.
seleniumhq.github.io#2556.
This charter is closer to what we agreed to 2 years ago just including the per-method fallback we discussed in Valencia.
#17709 presumably wants to remove the 2 "high level API" requirements below and roll that into a more comprehensive set of methods supporting
Required decisions
Each must be settled by an accepted ADR before 5.0 ships; none is accepted yet. Each ADR has to
consolidate both what we agreed to implement — the surface, much of it settled at the summits
before we used ADRs — and how it behaves. The existing PRs cover only parts of that.
line? #17670 proposes internal-only.
#17709 describes three layers but does not
say which is supported, why, or how they differ — so it does not yet define the boundary. The ADR
has to pin where supported ends and internal begins, and on what basis.
and authentication; #13993) and how
handlers behave (observe vs. intercept, disposition, ordering;
#17685). [adr] network handler behavior proposal #17685 covers only the behavior; the
agreed surface still needs to be folded into the same decision.
command fall back to Classic? No ADR yet;
#13995 and the navigation routing work are
partial inputs.
DOM-mutation handlers; #13992) and how it
behaves. No ADR yet.
defaults change when it leaves Beta. No ADR yet; issues
#11694,
#15754,
#17554.
Possible additions to consider
Subjects the charter defers; this PR is where we decide whether any should be required for 5.0. The
charter decides only whether a subject is in scope — each linked ADR is the design proposal
if it is. Each has an in-flight proposal:
fallback mechanism (navigation: #17715,
#17232, POC #13190).
expect_*event waiting (#17671),response body & request timing (#17674),
navigation waiting (#17676).
(#17681).
(#17677), storage / cookies
(#17673), emulation
(#17675), user prompts
(#17672).