An Introductory Guide to the WebDriver BiDi Protocol

In Selenium 4, the WebDriver bidirectional (BiDi) protocol has been implemented. First of all, you should know why WebDriver needs the BiDi protocol. First, the Selenium WebDriver client library sends HTTP command requests to a server. The received requests are then processed by the server. Once the server is ready with the response, it will send the response to the client.

So the Selenium WebDriver Remote server does not send any HTTP response or message to the client until it receives an HTTP request.

In the above diagram, the client sends a request and the server responds. The client does not kill the connection with the server until the response for a command request is received. Selenium WebDriver has more than 60 endpoints to communicate with a remote server.

Why BiDi Protocol?

The WebDriver Bi-Directional protocol allows both the client and the server to send & receive requests and responses. But we have enough HTTP commands to send requests to the server. Then why do we need the BiDi protocol? To understand this, you need to know some features which are available in Selenium 4.

• Listening DOM events
• Capture & send JS Errors and Console messages to client
• Record Traffic
• Access to native devtools protocol

Let’s take sending console messages to the client as an example. If a webpage has 100 console log messages, then the server needs to establish 100 HTTP connections and moreover, the server cannot send a response without a valid request from the client.

Even if the selenium developers tried to implement this feature with an HTTP connection, the server wouldn’t be able to handle multiple requests simultaneously. That is the reason why the BiDi protocol has come into the picture.

What is BiDi Protocol?

BiDi is a web-socket protocol. Websocket is an event-driven protocol. Let’s say the Selenium client wants JavaScript error messages from the browser. Whenever JavaScript errors are notified by the browser to the server, the error messages will be sent to the client. So the server will send the error message only when there is an error. This is called the event-driven protocol.

In the below diagram, you can see that server is sending the WebSocket URL to the client in the new session endpoint response. So any commands other than HTTP server endpoints will be communicated using the WebSocket URL.

When the client needs the JavaScript console error logs, then it should subscribe to the server so that the Selenium Server will send the error messages to the client from the browser.

Refer to the below snippet. The client subscribes to the Browser Log messages. So whenever any log message is added in DevTools, the server will send the message.

import org.openqa.selenium.WebDriver;
import org.openqa.selenium.chrome.ChromeDriver;
import org.openqa.selenium.devtools.DevTools;
import org.openqa.selenium.devtools.Log;
import org.slf4j.*;
 
public class Selenium4Devtools {
    final static Logger logger = LoggerFactory.getLogger(Selenium4Devtools.class);
 
    public static void main(String args[]){
        System.setProperty("webdriver.chrome.driver", "drivers/chromedriver.exe");
        WebDriver driver = new ChromeDriver();
 
        try{
            DevTools devTools = ((ChromeDriver)driver).getDevTools();
            devTools.createSession();
            devTools.send(Log.enable());
            devTools.addListener(Log.entryAdded(), entry -> logger.error(entry.asSeleniumLogEntry().getMessage()));
            driver.get("https://www.codoid.com");
        }
        catch(Exception e){
            e.printStackTrace();
        }
        finally {
            driver.quit();
        }
    }
}

Conclusion

As a leading automated functional testing services company, we have explored many Selenium 4 features, and the WebDriver BiDi protocol is certainly an interesting topic. It is pivotal for every automation tester to be familiar with the internal processes of Selenium.