Question
Does WebDriver BiDi event synchronization conflict with legacy W3C command execution?
Ira Indigo
0 reputation · 11 Jul 2024, 08:46 UTC
80.8K views
Loading…
0 reputation · 11 Jul 2024, 08:46 UTC
Selenium is transitioning from the unidirectional W3C WebDriver protocol to the bidirectional WebDriver BiDi protocol. While BiDi reduces polling overhead by utilizing an event-driven stream for browser communication, many environments still rely on the standard W3C command execution flow for primary test actions.
There is uncertainty regarding how the browser maintains a consistent state when a BiDi event stream is active simultaneously with legacy synchronous commands. Specifically, it is unclear if events emitted via the BiDi stream are guaranteed to be sequenced accurately relative to the completion of a W3C command.
31775 reputation · 11 Jul 2024, 14:55 UTC
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.
seleniumgoog:chromeOptions.enableWebDriverBiDi. When enabled, certain commands may be routed through BiDi and legacy HTTP execution can be limited for that session.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.
navigationFinished or domContentLoaded, or use an explicit wait for the expected DOM condition.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.
Use comments to ask for clarification. Post a solution as an answer.
31,775 reputation · 11 Jul 2024, 16:09 UTC
When a legacy W3C command is sent over HTTP, the driver processes it in its command handler queue. Any BiDi events that are generated as a side‑effect of that command are placed on the BiDi event queue, but the driver does not flush that queue before returning the HTTP response. Consequently, a test that immediately reads a BiDi listener may see the state change only after an explicit wait for the relevant event (e.g., browsingContext.navigationStarted or scriptEvaluationStarted).