Description

WebDriver BiDi is a new protocol for browser automation. It extends the “classic” WebDriver protocol by introducing bidirectional communication. In place of the strict command/response format of WebDriver, this permits events to stream from the browser to the controlling software, better matching the evented nature of the browser.

Rationale

Industry-wide surveys such as the MDN Web Developer Needs Assessment (2019, 2020) and the MDN Web Testing Report (2021) consistently identify cross-browser testing as one of the top developer pain points.

Browser automation plays a critical role in the space of cross-browser testing. However, existing automation solutions are either 1) built on proprietary protocols, preventing their use across a wider range of browsers (e.g. Puppeteer being based on CDP); or 2) built on top of the “classic” WebDriver protocol which lacks a) the efficiency of bi-directional communication (e.g. Selenium) as well as b) powerful capabilities to automate modern Web Platform features.

WebDriver BiDi closes the gap between these trade-offs. In 2019, browser vendors Mozilla, Apple, and Google agreed to focus on WebDriver BiDi as the standardized way forward. Having WebDriver BiDi as an Interop 2023 focus area would continue on this path, and hopefully accelerate the availability of BiDi for web developers.

Specification

https://w3c.github.io/webdriver-bidi/

Tests

The WebDriver BiDi test suite is actively growing.

• Here’s the live / always up-to-date view of the available tests:
  https://wpt.fyi/results/webdriver/tests/bidi?label=experimental&label=master&aligned (corresponding to https://github.com/web-platform-tests/wpt/tree/master/webdriver/tests/bidi).
• Here’s a snapshot of the currently available tests at the time of writing: https://wpt.fyi/results/webdriver/tests/bidi?run_id=5097986627993600&run_id=5175415929307136&run_id=5183267498622976&run_id=5071062014885888

For the purposes of this Interop 2023 proposal and scoring progress, we’d carve out a specific subset of these tests, so that we’re not operating against a wildly moving target. The specific tests directories/modules we propose including are: session, script, log, errors, and browsing_context.