BiDirectional WebDriver Protocol
w3c.github.io
w3c.github.io
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.
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.
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.