5 ms·

BiDirectional WebDriver Protocol

31 points by oedmarap 6y ago

neilalexander 6y ago
Can someone ELI5 why this is desirable?
- monocasa 6y ago
  Integration testing of frontend code
  - hulitu 6y ago
    ... and last but not least: RCE.
- jodoherty 6y ago
  WebDriver provides a standardized interface for automating web browsers. It makes building out automated cross-browser tests easier, since you can utilize all the browsers in the same way if they support it. It's mostly confined to use in automation and testing, not something a webpage would use with your browser as you browse the web. Currently, the protocol is request/reply from the client to the browser, so if you do commands involving a page and want to wait for something to appear (a dialog, a confirmation message, a notification, a changed element, etc.), you'd have to check the page over and over again in a loop of commands to inspect the page's state to see if the change happened. This BiDirectional spec would allow you to execute commands that tell the client to send commands back when certain browser events or DOM changes happen, allowing you to specify a callback handler that happens when the event triggers rather than having to poll with a loop. This makes implementing tests much easier and more consistent. One weakness of polling, for example, is that if something changes on the page and then changes back between your checks, then it'll appear as though it never happened. The BiDi spec makes it so you get events for the changes without having to worry about polling rates.
- diroussel 6y ago
  It seems you would be able to subscribe to events in your browser, and they could be sent from the browser back to your webdriver client without polling. This is already possible in the CDP (Chrome DevTools Protocol), so I guess it would help modernise webdriver, and allow other browsers to do similar things. For instance I have a test (written in webdriver.io) that loads my SPA, and subscribes to network events in ChromeDev Tools (via CDP, via Puppet, via webdriver.io). This means I can assert that all .js and .css files on the page loaded successfully with 200 status codes. At the moment I can only run this test in Chrome.
  - gsnedders 6y ago
    There's also the Firefox Remote protocol, which is effectively a subset of CDP. Safari/WebKit has many of the same things exposed over the Inspector protocol, but it's neither public nor stable. (And is the ultimate origin of CDP, prior to the Blink fork.) There's a variety of things that you can do with an event-based protocol rather than a pull-based one, such as providing the means to intercept network requests or provide interactive debugging.
- gsnedders 6y ago
  The explainer might be a better starting point: https://github.com/w3c/webdriver-bidi/blob/master/explainer.md https://github.com/w3c/webdriver-bidi/blob/master/explainer....

31 points by oedmarap 6y ago

neilalexander 6y ago

Can someone ELI5 why this is desirable?

monocasa 6y ago
Integration testing of frontend code
- hulitu 6y ago
  ... and last but not least: RCE.
jodoherty 6y ago
WebDriver provides a standardized interface for automating web browsers. It makes building out automated cross-browser tests easier, since you can utilize all the browsers in the same way if they support it. It's mostly confined to use in automation and testing, not something a webpage would use with your browser as you browse the web. Currently, the protocol is request/reply from the client to the browser, so if you do commands involving a page and want to wait for something to appear (a dialog, a confirmation message, a notification, a changed element, etc.), you'd have to check the page over and over again in a loop of commands to inspect the page's state to see if the change happened. This BiDirectional spec would allow you to execute commands that tell the client to send commands back when certain browser events or DOM changes happen, allowing you to specify a callback handler that happens when the event triggers rather than having to poll with a loop. This makes implementing tests much easier and more consistent. One weakness of polling, for example, is that if something changes on the page and then changes back between your checks, then it'll appear as though it never happened. The BiDi spec makes it so you get events for the changes without having to worry about polling rates.
diroussel 6y ago
It seems you would be able to subscribe to events in your browser, and they could be sent from the browser back to your webdriver client without polling. This is already possible in the CDP (Chrome DevTools Protocol), so I guess it would help modernise webdriver, and allow other browsers to do similar things. For instance I have a test (written in webdriver.io) that loads my SPA, and subscribes to network events in ChromeDev Tools (via CDP, via Puppet, via webdriver.io). This means I can assert that all .js and .css files on the page loaded successfully with 200 status codes. At the moment I can only run this test in Chrome.
- gsnedders 6y ago
  There's also the Firefox Remote protocol, which is effectively a subset of CDP. Safari/WebKit has many of the same things exposed over the Inspector protocol, but it's neither public nor stable. (And is the ultimate origin of CDP, prior to the Blink fork.) There's a variety of things that you can do with an event-based protocol rather than a pull-based one, such as providing the means to intercept network requests or provide interactive debugging.
gsnedders 6y ago
The explainer might be a better starting point: https://github.com/w3c/webdriver-bidi/blob/master/explainer.md https://github.com/w3c/webdriver-bidi/blob/master/explainer....