Get ready to experience a game-changing evolution in browser automation with WebDriver BiDi! 
Join Sri Harsha to learn about WebDriver BiDi and how it can be used in Selenium/WebdriverIO.
Still not registered? Hurry up and grab your free tickets: Register Now!
If you have already registered and up for the session, feel free to post your questions in the thread below 
Here are some of the Q&As from this session:
Are we going to see WebDriver BiDi in the mobile app as well?
Harsha: The possibility is high, but since WebDriver BiDi is still in the implementation stage, it might take some time for WebDriver BiDi to integrate with the mobile app.
Will there be any possibilities where we can incorporate cross-browser testing with desktop application testing?
Harsha: No, as the primary goal of BiDi is to provide devtool access to the WebDriver classics.
What strategies can be employed to address the challenges of implementing WebDriver BiDi?
Harsha: Currently, WebDriver BiDi is in the implementation stage. We are working on browser protocols for a couple of the team members working on implementing WebDriver. Yes, there are a few challenges as time progresses. The functionality is primarily deprecated, and things will get finalized, but we will implement it in the future.
BiDi is a direction to match the capabilities of Cypress. Does this have the potential to check all the powers of Cypress?
Harsha: Since there are a few limitations with Cypress, Handling Frames and windows becomes a bit difficult as Cypress is wholly based on web APIs, But as with the session, the WebDriver BiDi can overcome the Cypress limitations.
How do you see BiDi amongst its competitors?
Harsha: BiDi will rock the world of test automation soon, As there is implementation going on with WebDriver BiDi.
Can you explain more about Web platform Tests?
Harsha: Web Platform Tests is an open-source project that provides a collection of test cases designed to verify the correct implementation of web standards in different browsers.
The test is written in ways that run real-time scenarios and edge cases to ensure that browsers behave consistently and accurately. How it’s different from the Playwright web socket?
Harsha: Playwright’s WebSocket API enables direct interaction with the WebSocket endpoint during browser automation. In contrast, Web Platform Tests validate the browsers with web standards through test cases.
Are there any recommended best practices for incorporating WebDriver BiDi Into an organization’s broader testing strategy?
Harsha: There are recommended best practices for integrating WebDriver BiDi into an organization’s testing strategy.
Are there any self-healing features for WebDriver BiDi?
Harsha: WebDriver BiDi may automatically incorporate self-healing elements to handle minor script failures and continue execution without manual intervention.
What’s in store for WebDriver BiDi? Also, will CDP ever be deprecated once WebDriver BiDi gains more adoption, or will they co-exist?
Harsha: The end of WebDriver BiDi includes hypothetical improvement, increased adoption, and improved browser automation. Chrome DevTools Protocol (CDP) might continue to coexist with WebDriver BiDi because they serve different purposes, with CDP focusing on debugging and inspection while WebDriver BiDi is for browser automation. Both can complement each other to provide a comprehensive toolkit for developers and testers.
Now, let’s see some of the unanswered questions popped up by the attendees.
What are the challenges of implementing WebDriver BiDi?
Is WebDriver BiDi going to replace Chrome DevTools Protocol?
What are the top common cross browser compatibility issues to avoid?
Why Selenium BiDi is more beneficial over traditional WebDriver APIs?
What is the best process to mock a network?
Can you also address on rapid prototyping approach?
Can this be as fast as Playwright?
What will be the impact of Webdriver BiDi in near future?
Do you see BiDi as the future of browser automation?
