Skip to content

[🚀 Feature]: Implement Navigation Commands with BiDi #13995

Open

Description

@titusfortner

Feature and motivation

Moving forward, Selenium plans to update implementations to use WebDriver BiDi instead of WebDriver Classic if BiDi is enabled.

It was decided at the Selenium Dev Summit that we would implement the navigation commands with BiDi in all the bindings as the minimum for Selenium 5. This will act as a proof of concept that a user can successfully use either BiDi or Classic depending on the capabilities that are set. We do not need to implement everything in BiDi spec before releasing Selenium 5, just have a working module as a pattern to work from.

Considerations

  • let's not worry about making sure we're storing the browser context id properly everywhere for this issue
  • we do need to make sure we're looking at the user's page load strategy to determine how to wait for the navigation

Implementations

Activity

  1. added this to the Selenium 5.0 milestone on May 21, 2024
  2. added
    B-devtoolsIncludes everything BiDi or Chrome DevTools related
    on May 21, 2024
  3. github-actions commented on Dec 30, 2024

    @github-actions
    Contributor

    This issue is stale because it has been open 280 days with no activity. Remove stale label or comment or this will be closed in 14 days.

  4. added
    J-staleApplied to issues that become stale, and eventually closed.
    on Dec 30, 2024
  5. github-actions commented on Jan 13, 2025

    @github-actions
    Contributor

    This issue was closed because it has been stalled for 14 days with no activity.

  6. reopened this on Jan 13, 2025
  7. removed
    J-staleApplied to issues that become stale, and eventually closed.
    on Jan 13, 2025
  8. modified the milestones: Selenium 5.0, 6.0 on Dec 15, 2025
  9. krishnamohan-kothapalli commented on Mar 2, 2026

    @krishnamohan-kothapalli

    Hi, I'd like to work on the Java implementation for this issue.

    My plan:

    • Modify the RemoteNavigation inner class in RemoteWebDriver.java to route get(), back(), forward(), and refresh() through BiDi when it's enabled, falling back to Classic otherwise
    • Map the driver's pageLoadStrategy capability to the appropriate ReadinessState (normal → COMPLETE, eager → INTERACTIVE, none → NONE)
    • Add integration tests covering the navigation commands with BiDi enabled

    Please let me know if this approach looks right or if there's anything I should be aware of before I start. Happy to adjust based on feedback!

  10. added 7 commits that reference this issue on Mar 17, 2026
    fffa6c7
    1c8ef74
    9e6b74a
    8841555
    c9f071a
    78ce161
    50a7aac
  11. shossain786 commented on Jun 24, 2026

    @shossain786

    I've opened #17715 implementing the Python binding for this, following the merged Ruby PR (#14094) and the in-review Java PR (#17232).

    It routes the Classic navigation commands through the BiDi browsingContext module when BiDi is enabled (webSocketUrl present), falling back to Classic otherwise:

    Classic BiDi
    driver.get(url) browsing_context.navigate(context, url, wait=<readiness>)
    driver.back() browsing_context.traverse_history(context, delta=-1)
    driver.forward() browsing_context.traverse_history(context, delta=1)
    driver.refresh() browsing_context.reload(context, wait=<readiness>)

    pageLoadStrategy maps to readiness state (normal → COMPLETE, eager → INTERACTIVE, none → NONE).

    One design question for the maintainers: unlike Ruby's dedicated BiDiBridge, the Python binding has a single WebDriver class, so the PR uses an inline if self._is_bidi_enabled() branch in the four navigation methods. Happy to refactor to a separate bridge/mixin if that's preferred for the Selenium 5 direction. Feedback welcome!

  12. naveenprakash82 commented on Oct 13, 2026

    @naveenprakash82

    Hi, I am interested in contributing to the WebDriver BiDi navigation implementation, particularly in the Java bindings.

    I have experience in browser automation, test framework development, and test reliability. I would like to contribute to the implementation and strengthen regression coverage in the following areas:

    1. Page load strategies: Validate navigation behavior for normal, eager, and none, including the expected wait conditions and completion behavior.
    2. Navigation lifecycle: Verify event handling for browsingContext.navigationStarted, browsingContext.domContentLoaded, and browsingContext.load.
    3. Timeouts and failures: Cover navigation timeouts, redirects, interrupted navigation, and page load failures.
    4. BiDi and Classic consistency: Validate return values, exception handling, and page load behavior across both protocols.
    5. Cross-browser testing: Add regression coverage for Chrome and Firefox, where the required BiDi functionality is supported.

    I would prefer to build on the existing Java implementation and focus on areas that still need attention.

    Please let me know which part would be most useful to take up. I can review the current implementation, work on the required changes, and submit a pull request with relevant tests.

  13. titusfortner commented on Oct 13, 2026

    @titusfortner
    MemberAuthor

    I think we're going to need an ADR for what this needs to look like. I started drafting one but ended up down a rabbit hole figuring out Capabilities ADR which is related.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    B-devtoolsIncludes everything BiDi or Chrome DevTools relatedC-dotnet.NET BindingsC-javaJava BindingsC-nodejsJavaScript BindingsC-pyPython BindingsC-rbRuby BindingsI-enhancementSomething could be bettergood first issueGood first issue for new contributors to start with

    Type

    No type

    Projects

    No projects

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions