Selenium BiDi Java Breaking Change: What Developers Need to Know

Direct answer: When using Selenium Java 4.19 or later, change the imports for the affected WebDriver BiDi module classes from org.openqa.selenium.bidi to org.openqa.selenium.bidi.module. Selenium says the BiDi APIs themselves stay as they are; this breaking change is an import-path update.

The migration boundary documented by Selenium is version 4.19. Check the Selenium version resolved by your build, then update the affected imports and compile the project to find any additional references. See Selenium’s official BiDi Java migration article.

What changed

Selenium moved classes that call BiDi commands or events into a module package. The official migration examples name these five classes:

Class	Before 4.19	4.19 and later
LogInspector	org.openqa.selenium.bidi.LogInspector	org.openqa.selenium.bidi.module.LogInspector
BrowsingContextInspector	org.openqa.selenium.bidi.BrowsingContextInspector	org.openqa.selenium.bidi.module.BrowsingContextInspector
Input	org.openqa.selenium.bidi.Input	org.openqa.selenium.bidi.module.Input
Script	org.openqa.selenium.bidi.Script	org.openqa.selenium.bidi.module.Script
Network	org.openqa.selenium.bidi.Network	org.openqa.selenium.bidi.module.Network

Before and after imports

For Selenium versions before 4.19, the imports shown in the migration article look like this:

import org.openqa.selenium.bidi.LogInspector;
import org.openqa.selenium.bidi.BrowsingContextInspector;
import org.openqa.selenium.bidi.Input;
import org.openqa.selenium.bidi.Script;
import org.openqa.selenium.bidi.Network;

For Selenium 4.19 and later, change the package for those classes:

import org.openqa.selenium.bidi.module.LogInspector;
import org.openqa.selenium.bidi.module.BrowsingContextInspector;
import org.openqa.selenium.bidi.module.Input;
import org.openqa.selenium.bidi.module.Script;
import org.openqa.selenium.bidi.module.Network;

This is a source change: update the imports wherever those types are referenced. The migration article says the APIs remain as they are, so this package move alone does not call for changing how those APIs are used.

How to migrate a Java project

1. Check the resolved Selenium version. Inspect the dependency declaration and, if your build uses dependency management or a lockfile, confirm the version actually selected. The import boundary in Selenium’s migration article is 4.19.
2. Find BiDi imports. Search Java source for org.openqa.selenium.bidi.. Review the matching imports and identify references to the moved module classes.
3. Update affected package names. Change the five imports listed above to org.openqa.selenium.bidi.module. Do not mechanically change every BiDi-related name without checking its class: the documented examples identify affected classes, not a blanket rule for every type in the BiDi namespace.
4. Compile the project. A compile can reveal affected imports in less obvious source sets, generated code, or test code. This is practical migration advice based on the documented source-level change.
5. Review any remaining errors by symbol. For a missing type, check whether its package moved and whether the project resolves the Selenium version you expect. For errors unrelated to imports, investigate them separately; the migration article does not describe them as consequences of this package change.

Search examples

From a repository root, rg can locate Java imports that begin with the old package prefix:

rg -n 'import org\.openqa\.selenium\.bidi\.' --glob '*.java' .

To look for the five specific class names across Java files, including references that may need review:

rg -n 'LogInspector|BrowsingContextInspector|\bInput\b|\bScript\b|\bNetwork\b' --glob '*.java' .

The second search is intentionally broader: names such as Input, Script, and Network may appear in unrelated code. Inspect matches before editing.

Why Selenium moved the classes

Selenium described the package reorganization in the context of implementing the W3C WebDriver BiDi protocol and working toward a future where WebDriver Classic APIs could use BiDi APIs under the hood. During work on the BiDi browsingContext.locateNodes command, Selenium encountered a circular dependency in Bazel. It grouped BiDi classes for a module into a Bazel package and placed classes that call commands or events under a module package.

The change was difficult for Selenium to handle through its usual deprecation path. The project also cautions that BiDi is under development, so protocol modules and APIs may be added or changed. Selenium says it strives to avoid breaking changes and to deprecate APIs for at least two versions before removal; the migration article explains why this package reorganization was an exception.

Keep the import move separate from later BiDi changes

The 4.19 import update is specific: use the new package for the affected classes. BiDi development continued after that release. Selenium’s 4.19.0 changelog lists additional BiDi work, including storage and browser modules, network request and response commands, and an Input module command. Its 4.19.1 section records a Bazel-file fix after the breaking change.

Later changes do not alter the basic migration instruction. For example, Selenium’s February 20, 2026 announcement for 4.41 describes Java BiDi nullability coverage and a JSON parsing fix for exponent-form numbers. Those are later development details, not extra steps required to update the imports. See the Java changelog and the Selenium 4.41 release announcement.

Version context

Selenium’s downloads page listed Java 4.49.0 as stable and 4.50.0-SNAPSHOT as a nightly build when checked on October 3, 2026. That listing changes over time; check the Selenium downloads page and your project’s resolved dependency version when applying this guidance.

The import rule in this article is tied to the 4.19 boundary documented by Selenium. It is not a browser and driver compatibility matrix, and it does not establish that every browser and driver combination has identical BiDi support.

Troubleshooting

Symptom	Likely cause	What to do
package org.openqa.selenium.bidi does not exist for one of the listed classes	The source still uses the pre-4.19 package while the resolved Selenium version uses the new path.	Change that class’s import to org.openqa.selenium.bidi.module and confirm the resolved dependency version.
package org.openqa.selenium.bidi.module does not exist	The project may still resolve a Selenium version before 4.19, or its dependency declaration may differ from the version you expected.	Check the build’s resolved Selenium version. Use the package that matches that version, or align the dependency and imports intentionally.
Some BiDi imports compile while one does not	Not every BiDi type should be assumed to follow the same package change; the migration article lists specific affected module classes.	Check the failing class’s package in the documentation for the version being used. Avoid changing unrelated imports solely because they share the bidi prefix.
Compilation still fails after changing the imports	There may be another stale import, a different resolved dependency, or an unrelated source error.	Read the first compiler error, search all source sets for the named class and old import, then check the dependency resolution. Treat unrelated API or browser support issues separately.
The code compiles but BiDi behavior differs at runtime	The import migration addresses Java package names; it does not promise identical BiDi support for every browser and driver combination.	Check the relevant browser, driver, and Selenium compatibility information for the runtime behavior. The import article alone does not provide that matrix.

Performance, reliability, and cost considerations

• Performance: The documented change is a Java import-path change. The migration article does not identify a runtime performance change caused by updating these imports.
• Reliability: Confirm the dependency version that the build actually resolves, update the affected source imports, and compile all relevant source sets. BiDi remains under development, so review release notes when upgrading beyond this narrow migration.
• Cost: The import edit itself has no stated Selenium fee. Any broader infrastructure or browser execution costs depend on your project and are outside the scope of the migration article.

Or skip the browser setup

If you also need website screenshots for documentation, reports, or an AI workflow, ScreenshotNeo is a separate option: a website screenshot API and MCP server for developers. Its one-call API can return a PNG, JPEG, WebP, or PDF.

curl -G "https://api.screenshotneo.com/v1/shot" -d access_key=YOUR_API_KEY --data-urlencode url=https://stripe.com -o shot.webp

See the ScreenshotNeo API documentation for request options. Cookie banners, popups, and chat widgets are removed before capture; bot checks, blank pages, and failed loads are never billed. An MCP server lets AI agents take screenshots. The free plan includes 1,000 screenshots a month with no card, and paid plans start at $5 for 3,000. Sign up for 1,000 free screenshots a month, with no card.

FAQ

Does this change require rewriting BiDi calls?

The migration article says the BiDi APIs stay as they are. The change it documents is to the import statements for affected classes.

Is the package move the same as a Selenium 4.19 dependency upgrade?

No. The package move is the source adjustment to make when using the affected classes with Selenium 4.19 and later. Your dependency version is controlled by your project’s build configuration.

Does the import guidance guarantee browser support for every BiDi feature?

No. It explains Java package names, not a browser and driver support matrix. Check compatibility information relevant to the browser and driver you use.

Sources

• Selenium: Update imports to use BiDi Java (March 14, 2024).
• Selenium downloads (release listing checked October 3, 2026).
• Selenium Java changelog.
• Selenium 4.41 release announcement (February 20, 2026).