webdriver
webdriver copied to clipboard
Published
20 hours ago •
w3c
w3c
Proposal: upgrade path from WebDriver to bidirectional DevTools Protocol
Just want to keep track of what we have discussed at TPAC in Lyon about the topic of upgrading to a bidirectional connection. With that I want to just put the points in here on which we agreed on so far. I left out the part where we shortly talked about the permission standard and details about logging.
Motivation
- there is a demand for being able to directly talk to the DevTools protocol to be able to introspect the browser (e.g. listen to events to find out when things have changed)
- it helps implement better logging capabilities (no ring buffer)
- there is a WICG initiative that tries to define a standard for devtools protocols that doesn't not bind vendors to implement that certain protocol but creates some sort of common interface
Concerns
- the Devtools protocol is not semantically defined, WebDriver is
- therefor it is hard to spec this feature set
- exposing devtools protocol functionality (e.g. callfunctionon exposes to much of implementation detail that we want to hide
Proposal
- WebSocket server on browser driver ("upgrade" connection on demand)
- one socket per browser session
- driver has to multiplex sockets to browsing context
- we don't want to expose hundreds of sockets for each tab or browsing context, that doesn't scale
- socket connection will be established on demand
Resolutions
- There will be a capability that lets you ask for a CDP-derived remote protocol. This will take a boolean, and if true and the remote end can fulfil the capability request, will return a string URL to the WebSocket for said protocol. It will return null by default.
- The WebSocket endpoint will be hosted by the WebDriver remote end and act as a multiplexer for CDP target domains (browsing contexts, servicework, et al.). This will take a web window ID to identify the target domain
@christian-bromann I assume that we can finally close this issue now given the process we have made so far? Nothing from the above seems to be left. It's only PR #1608 that needs to be reviewed and landed which refactors the session handling in HTTP for a better BiDi integration.
