[HN Gopher] BiDirectional WebDriver Protocol
       ___________________________________________________________________
        
       BiDirectional WebDriver Protocol
        
       Author : oedmarap
       Score  : 26 points
       Date   : 2021-04-10 11:23 UTC (1 days ago)
        
 (HTM) web link (w3c.github.io)
 (TXT) w3m dump (w3c.github.io)
        
       | neilalexander wrote:
       | Can someone ELI5 why this is desirable?
        
         | gsnedders wrote:
         | The explainer might be a better starting point:
         | https://github.com/w3c/webdriver-bidi/blob/master/explainer....
        
         | monocasa wrote:
         | Integration testing of frontend code
        
         | jodoherty wrote:
         | 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 wrote:
         | 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 wrote:
           | 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.
        
       ___________________________________________________________________
       (page generated 2021-04-11 23:02 UTC)