🌐 Chrome DevTools (CDP) & WebDriver BiDi
Chrome DevTools (CDP) & WebDriver BiDi: Before Selenium 4, WebDriver communication with the browser was strictly one-directional: test code sends a command, the browser executes
Before Selenium 4, WebDriver communication with the browser was strictly one-directional: test code sends a command, the browser executes it, the result comes back as an HTTP response — identical to a classical blocking REST call in Java. WebDriver BiDi (Bidirectional Protocol) converts this into a persistent WebSocket tunnel: similar to a Java CompletableFuture + event listener architecture, you can now receive real-time events pushed from the browser (console error fired, network request intercepted, JavaScript exception thrown). If HTTP-based WebDriver already works, why does BiDi matter? Because certain test scenarios require reacting to events as they happen: detect when an authentication dialog appears, capture a network failure event for a broken image, pipe console.error() output into your CI log. None of this is possible with classic WebDriver. The concrete QA gain: with BiDi you can add "assert no JavaScript errors occurred during this page interaction" to every E2E test without touching the source code — effectively catching silent JavaScript exceptions before they reach production.
Selenium 4 introduces the W3C WebDriver BiDi protocol and Chrome DevTools Protocol (CDP) integrations, allowing bidirectional WebSocket communication. This enables your test code to listen to browser events, intercept network requests, and modify browser behaviors in real time.
In Java, CDP sessions are initialized via `driver.getDevTools()`. For BiDi, high-level helper classes like `LogInspector` or `NetworkInterceptor` manage the WebSocket connection automatically, closing the gap with Playwright's event-driven architecture.
1. Console Log & JS Exception Listening
Java — Console Log Listener
Micro Lab: Selenium — Debug and Screenshot
Replace the TODO line with the critical line from the expected solution. This is not a real runtime; the goal is to reinforce writing the correct structure in a controlled way.
Step by Step: What Happens Between createSession() and addListener()
getDevTools() opens a WebSocket TUNNEL
`driver.getDevTools()` establishes a WebSocket connection DIRECTLY with the browser, SEPARATE from the standard HTTP WebDriver protocol.
createSession() ACTIVATES CDP
Without `devTools.createSession()`, CDP commands do NOTHING — this call makes the browser start LISTENING via the Chrome DevTools Protocol.
Log.enable() turns on a specific DOMAIN
`devTools.send(Log.enable())` activates ONLY the "Log" domain among CDP's dozens of domains (Network, Page, Log...) — this avoids unnecessary event traffic.