Answer
No hard protocol conflict exists. WebDriver BiDi and legacy W3C commands can run in the same session, but the BiDi event stream is not strictly chronologically synchronized with W3C command execution. A state change made by a W3C command is visible to BiDi only via asynchronous events, and a BiDi-initiated change is visible to W3C only after the driver’s internal state is updated. There is no built-in cross-channel barrier that guarantees ordering between the two channels.
Confirmed facts
- BiDi operates over a separate WebSocket channel while legacy W3C commands use the standard HTTP endpoint. The two mechanisms are independent at the protocol level.
- Mainstream drivers that support BiDi allow both BiDi and legacy commands in the same WebDriver session. The same session ID is used for both channels and the driver maintains a single browser state.
- Some drivers expose a capability to enable BiDi, e.g.
goog:chromeOptions.enableWebDriverBiDi. When enabled, certain commands may be routed through BiDi and legacy HTTP execution can be limited for that session.
Likely explanation
Conflicts are timing issues, not protocol incompatibilities. If a test issues a BiDi command that changes page state, such as navigation or DOM mutation, while a legacy W3C command is in flight, race conditions and stale element errors can occur. The W3C command returns when the browser reports completion for that HTTP request, while BiDi events are emitted asynchronously. Without explicit coordination, the next W3C command can be issued before the BiDi event stream has been processed by the test.
Steps needed for this case
- Start a session with BiDi enabled and verify both channels are active. Confirm the driver version supports concurrent BiDi and HTTP use.
- Issue a state-changing action via one channel and immediately issue a legacy command via the other to observe ordering behavior.
- Add explicit synchronization before the legacy command: wait for the relevant BiDi event, e.g.
navigationFinished or domContentLoaded, or use an explicit wait for the expected DOM condition.
- Repeat with BiDi disabled to confirm baseline legacy behavior, and check driver release notes for documented limits on mixing channels.
Best practice is to use BiDi exclusively or legacy exclusively per scenario. If both must be used, serialize state-changing operations and use explicit waits or event listeners to ensure page state is stable before issuing the next command.
One missing diagnostic detail that changes the recommendation: Are you executing navigation or DOM-modifying actions via BiDi while simultaneously sending legacy W3C commands? If yes, serialization and event-based waits are required; if you only use BiDi for passive observation, the risk is lower.
selenium