How does BiDi improve visibility into browser console logs and JavaScript errors during tests?
Which browsers currently support WebDriver BiDi, and what’s the roadmap for broader adoption?
In the next 2–3 years, do you expect WebDriver BiDi to fully replace the JSON Wire Protocol, or will both co-exist for some time?
Can BiDi help capture the Page load metrics for Performance Evaluation?
Can you explain a scenario where subscribing to network events would help validate application behavior?
Absolutely! After attending the session by Maksim, one thing became really clear: BiDi isn’t here to replace your existing frameworks like Selenium, Playwright, or Cypress. Instead, it works with them.
Think of it as adding a “live connection” between your tests and the browser. With a bit of wrapper logic, you can hook BiDi events into your usual scripts. That means while your existing framework handles the main test flow, BiDi can react to real-time browser events like network changes or console logs without waiting for the test to move to the next step.
In short, you don’t have to throw out what’s already working. You just make it smarter and more responsive with BiDi.
Not really. WebDriver BiDi isn’t here to replace CDP, but to make things more consistent across different browsers. Think of it this way: CDP (Chrome DevTools Protocol) is great, but it’s tied to Chromium-based browsers like Chrome or Edge. So if you wanted to do the same kind of automation in Firefox, things would get tricky.
That’s where BiDi comes in. It’s a W3C standard that brings a common language for browser automation that works across browsers. What’s cool is that it lets you react to events in real time, like network requests or console logs, without relying on browser-specific hacks.
So in short, CDP stays useful for deep Chrome debugging, but BiDi is what makes reactive testing smoother, standardized, and future-ready across browsers.
From what I gathered in Maksim’s session, the biggest difference really comes down to standardization. Chrome DevTools Protocol (CDP) is great but it’s tied to Chrome-based browsers. So if you’re testing across browsers, you’ll quickly hit limits.
WebDriver BiDi, on the other hand, is designed to be cross-browser. It already works with Firefox, and more browsers are joining in. What’s even cooler is how reactive it feels. Instead of constantly polling the browser for updates (which CDP often needs), BiDi works through an event-driven, two-way communication. That means your tests can respond instantly to what’s happening in the browser, making them faster, cleaner, and easier to maintain.
In short, BiDi takes the best ideas from CDP but makes them standardized and smarter for modern, multi-browser testing.
Honestly, watching BiDi in action felt like a breath of fresh air for anyone who’s struggled with flaky tests. In the old WebDriver setup, we were basically in a constant “Hey browser, are you ready yet?” loop, polling for updates, waiting for elements, hoping things lined up just right.
With BiDi, that changes completely. Instead of asking the browser over and over, we just listen. The browser tells us when something happens, like a navigation, a network call, or a console log, in real time. It’s like moving from a one-way conversation to a live chat.
The result? Tests feel snappier, more stable, and a lot less error-prone. You spend less time waiting and debugging timing issues, and more time actually validating user behavior. It’s a small shift in concept but a huge leap in how we think about browser testing.
That session by Maksim Sadym was a real eye-opener! The idea of combining WebDriver BiDi with AI takes browser testing to a whole new level.
Imagine this: while your test is running, the browser starts streaming real-time events like network failures, console errors, or DOM changes. Traditionally, your test would just fail, and you’d dig through logs later. But with AI in the mix, it can actually react on the spot.
If a network glitch happens, instead of crashing, the AI could pause, retry the step, or even reroute the flow based on the situation. If a console error shows up, it could analyze the message, decide whether it’s critical, and log meaningful insights automatically.
In short, it’s like giving your test scripts a bit of common sense they stop being rigid and start adapting in real time. That’s what makes testing truly “reactive” instead of just automated.
Honestly, what really stood out to me from Maksim’s session was how much simpler life gets with WebDriver BiDi when it comes to maintaining tests. Unlike traditional scripts that follow a fixed, step-by-step flow, BiDi-based tests actually react to what’s happening in the browser in real time.
That means if there’s a small DOM change or a browser update, your tests don’t just crumble they adapt. You spend less time fixing broken scripts and more time actually improving test coverage. It feels like moving from “fragile automation” to “resilient testing.” In short, reactive testing with BiDi keeps your test suite future-ready and much easier to maintain as browsers evolve.
That’s a great question — and Maksim explained this really well in the session.
With WebDriver Classic, we’ve always had to follow that “ask and wait” pattern: send a command, wait for the browser to respond, maybe add a few fixed waits or retries just to be safe. It works, but it often feels a bit clunky like you’re constantly asking, “Hey browser, are you done yet?”
Now with WebDriver BiDi’s real-time event listening, that changes completely. Instead of waiting around, your test can react instantly to what’s happening in the browser whether it’s a network request finishing, a console message popping up, or a DOM element changing.
Think of it like moving from a passive observer to an active participant. Your tests become smarter and more responsive, adapting as the browser emits events. This makes them not only faster but also more reliable, since you’re syncing with real browser behavior rather than guessing timing with arbitrary waits.
In short, it’s less about waiting for the right moment and more about flowing with the moment.
Honestly, what stood out to me about WebDriver BiDi is how much smoother it makes everything. With the old WebDriver setup, you often had to write a bunch of extra code just to handle things like async events, network tracking, or logs it felt clunky.
With BiDi, all that gets way easier. It’s more reactive meaning your tests can respond instantly to what’s happening in the browser instead of constantly polling or waiting. You can monitor network calls, catch console errors, or even track user actions in real time without all the boilerplate.
The end result? Tests that are cleaner, faster, and much simpler to maintain. It’s like going from manual gear shifts to an automatic same destination, just a smoother drive.
That’s a great question and honestly, this is where BiDi really shines compared to the classic WebDriver model.
With WebDriver Classic, we’re used to a “check and wait” kind of approach the script keeps asking, “Hey, is that element ready yet?” or we end up adding those dreaded sleep() statements just to be safe. It works, but it’s not the most efficient or reliable way to sync things up.
BiDi flips that idea completely. Instead of constantly polling, it listens for real-time browser events. So the moment something happens like a page load, network request, or console log your test knows instantly and can respond right away.
The result? Tests that feel more “reactive” and less flaky. You don’t waste time waiting unnecessarily, and your feedback loop becomes much tighter. It’s like moving from constantly refreshing a page to getting instant notifications when something changes.
The main advantage of WebDriver BiDi is that it’s built as a W3C standard, meaning it works consistently across different browsers Chrome, Firefox, Edge, and others. So instead of writing browser-specific logic (like we had to do with Chrome DevTools Protocol, which only works with Chrome), you can now write your test once and expect it to behave the same way everywhere.
In simple terms, BiDi brings everyone to the same table. You don’t need to juggle separate implementations for each browser, which saves a ton of time and effort. It also makes your tests easier to maintain and more reliable in the long run.
So, think of WebDriver BiDi as a unified language for browsers one that helps you build truly cross-browser reactive tests without the usual headache of compatibility issues.
Watching Maksim Sadym’s session really made it click for me, WebDriver BiDi completely changes how we think about browser testing. Instead of tests being these rigid, step-by-step scripts that just tell the browser what to do, they can now actually listen and react to what’s happening inside the browser in real time.
It’s like moving from a one-way conversation to an interactive dialogue your tests can now “observe” events as they happen (like console errors, network requests, or DOM updates) and respond intelligently. This makes testing feel much more natural and adaptive, almost like the tests are alive and aware of the browser’s behavior rather than just following a script blindly.
That’s a great question and Maksim explained it really well in his session.
Think of traditional browser automation like following a strict recipe: you take one step, check the result, then move on to the next. It’s predictable, but also rigid if something unexpected happens, your script usually breaks.
Reactive browser testing, on the other hand, is more like having a real-time conversation with the browser. Using WebDriver BiDi, your test can listen and respond as things happen for example, catching network events, console logs, or page updates right when they occur. Instead of waiting for a command, it adapts on the fly.
In short, while traditional tests just execute instructions, reactive testing reacts making it feel much closer to how real users actually interact with a browser.
What really stood out to me about BiDi is how it changes the whole debugging experience. With WebDriver Classic, you usually had to wait for the test to finish and if something went wrong, you’d rerun it again (and again) just to catch what happened.
But with BiDi, you can actually watch things unfold in real time. You can see network requests, console logs, and JavaScript errors as the test runs almost like having a live feed of what’s going on inside the browser. It saves so much time and helps you zero in on the issue right when it happens, instead of chasing it later.
That part of the session really got me thinking the concept of self-governing tests is pretty exciting! Imagine AI watching your test runs in real time, spotting something unusual through BiDi streams, and then deciding what to do next whether to pause, reroute, or keep going. It’s like giving your tests a bit of situational awareness.
This could be a game-changer, especially for complex or dynamic workflows where static test scripts often break down. Instead of failing outright, your tests could adapt on the fly kind of like a smart co-pilot that helps you navigate unexpected changes during runtime.
For this workshop, we used Visual Studio Code (VS Code) mainly because it just makes life easier. 
It’s lightweight, easy to set up, and comes with a great set of extensions that help you write, debug, and test your code in real time. Plus, with BiDi, having that live debugging support in VS Code really helps you see what’s happening behind the scenes as you test your browser interactions.
So if you’re planning to try out WebDriver BiDi yourself, VS Code is a solid choice to get started quickly.