Update goals in the explainer document

[jgraham]

Copying in feedback from email (it may make sense to split this into multiple issues if any of this is contraversial):

• This section captures a number of use cases, but I think there's a product-oriented view which is that we should be looking to provide the functionality that allows existing remote-automation libraries with browser-specific backends (or browser-specific features) to use a standard backend. This includes e.g. puppeteer, playwright, cypress, selenium, saucelabs.

• Some of these goals like "fail fast on any js error" seem like details of possible designs that can be discussed in the relevant features rather than top-level goals.

• "Access to native devtools protocol" shouldn't be an explicit goal. Having a way to support vendor extensions should be a goal (as you'd expect since WebDriver already has this capability). But for Firefox we don't anticipate building on the devtools protocol, and a requirement to expose that would significantly complicate things for us with little gain. Moreover starting a standard with the explicit goal of exposing nonstandard parts of implementations seems like it rather misses the point; we want a standard featureset that covers all the important cross-browser use cases so that people don't have to reach for the single-browser escape hatch at the cost of interop.

• The "easy mapping to native devtools protocol" doesn't seem like a goal for the protocol; for example we don't expect it to have a trivial mapping to RDP used in Firefox. Vendors may of course have constraints on the technical direction of the protocol which will derive from a shared implementation with their devtools, but those should form part of the discussion rather than be an explicit goal.

• An additional goal that we'd like to see is that the BiDi protocol ends up as a superset of the HTTP-based protocol i.e. there's never a requirement to send HTTP commands to get access to specific functionality. From an implementation point of view that would allow the HTTP-based and BiDi functionality to end up sharing all the code except for the transport layer.

[christian-bromann]

• we want a standard featureset that covers all the important cross-browser use cases

Can we define this standard feature set as a goal too? If I remember correctly there was a general consensus around the fact that the WebDriver spec needs to add more capabilities to meet todays developer needs. While the current BiDi discussion is more around the transport layer I wonder if we could add functionality on top of the current spec leveraging the new protocol capabilities. In my point of view the current protocol lacks in ability to:

• access network events as well as capabilities for network stubbing
• access a11y primitives
• emulate environments (geolocation, user agent, viewport dimension, pixel ratio)
• debug execution environments (handling breakpoints)

If there would be a scope for such feature set in the explainer it would help participants to chime in with proposals. Even if the consensus is not to add anything new but agreeing on including such capabilities later on, proposals can be written with the new BiDi structure in mind.

[jgraham]

Can we define this standard feature set as a goal too?

Fully agree that we should consider features on top of WebDriver 1.0 to be in-scope; note the first point above "we should be looking to provide the functionality that allows existing remote-automation libraries with browser-specific backends (or browser-specific features) to use a standard backend. This includes e.g. puppeteer, playwright, cypress, selenium, saucelabs.".

Concretely I suggest we proceed by splitting the new spec work up into several documents covering different parts of the stack e.g. core, script execution, logging, etc. Where there are not so many cross-dependencies that will allow us to iterate faster with different people working on different parts of the protocol. Of course care will be needed to ensure we end up with a coherent design, so careful review and refactoring will be required. But it avoids head-of-line blocking (means we don't need the whole core done before we can have a proposal for how logging should work, for example).

[foolip]

There was some discussion of this in the WebDriver/BiDi 2020-04-20 meeting, linking here for ease of discovery. The discussion was short, and mostly about the "easy mapping to native devtools protocol" goal. Not all implementations will necessarily be build on top of a devtools protocol, so this isn't an intrinsic goal.

However, when the implementation is layered that way there will be considerations about whether to support concurrent use of both protocols (for ease of transition), whether IDs are the same, etc.

[foolip]

The goals are now in https://github.com/w3c/webdriver-bidi/blob/master/explainer.md#goals (no change, just moved around)