Add an Automation section with WebDriver support to the spec

[rakuco]

Add WebDriver endpoints which allow manipulating virtual pressure sources, which are pressure sources whose behavior and samples are entirelly user-controlled. Also contrary to regular pressure sources, the provided samples (or, in spec parlance, a virtual pressure source's latest sample's data) are already PressureState instances rather than raw telemetry data that will be transformed into an adjusted pressure state.

Caveats:

• Shared workers are unsupported at the moment (i.e. the WebDriver endpoints only have an effect on Window and DedicaredWorkerGlobalScope globals). Storing virtual pressure source information in a top-level traversable does not play well with shared workers, for which the concept is somewhat irrelevant. We need to think of a different solution in the future if support for shared workers is important.
• Once PressureObserver.observe() resolves, the same platform collector will be used until disconnect() or unobserve() are called. In other words, if a PressureObserver instance is active and using a real pressure source, adding a virtual pressure source of the same type will only have an effect on it and other instances in the same global once they all disconnect from the existing pressure source first.

In terms of changes to the existing algorithms and concepts:

• A top-level traversable has a mapping of source types to virtual pressure sources that is manipulated by the WebDriver endpoints.
• When creating a new platform collector, PressureObserver.observe() first attempts to use a virtual pressure source when one exists and can be used.
• The data collection algorithm distinguishes between the data format used by a virtual pressure source (which already is a PressureState) and by a real pressure source (which needs to be transformed into a PressureState).

Co-authored with @kenchris in #265. It was split off as a separate pull request to make it easier to review and understand.

Fixes #282.

---

Preview | Diff

[rakuco]

As with #283, this is part of #265 but sent separately to make it easier to review.

[OrKoN]

@rakuco would you be interested in defining the API as a WebDriver BiDi module as well? testdriver.js actions can also be defined in terms of WebDriver BiDi commands (https://github.com/web-platform-tests/rfcs/pull/185).

[rakuco]

@rakuco would you be interested in defining the API as a WebDriver BiDi module as well? testdriver.js actions can also be defined in terms of WebDriver BiDi commands (web-platform-tests/rfcs#185).

@OrKoN would there be any advantage to it? So far I've been under the impression that if an endpoint/action doesn't need WebDriver BiDi's bidirectional and event monitoring capabilities, defining a classic endpoint would be fine and achieve the same results.

[OrKoN]

@rakuco defining it as a WebDriver BiDi module would allow adding events later (if needed) and it would allow WebDriver BiDi-only clients such as Puppeteer to expose the functionality for developers to write tests for their apps. Although, if you only target WPT and do not need events right now, there are probably no advantages.

[rakuco]

Hmm, I thought Puppeteer and others like Playwright ended up using CDP directly, but it's been quite a while since I last checked. Thanks for the clarification about this.

One of the first priorities is WPT at the moment, but I've filed #288 to keep track of this as a future enhancement.

[OrKoN]

@rakuco Thanks! Puppeteer has been historically CDP-only but since some time ago we have WebDriver BiDi support https://pptr.dev/webdriver-bidi The WebDriver BiDi progress can be tracked here https://puppeteer.github.io/ispuppeteerwebdriverbidiready/ Implementation of WebDriver BiDi for Chrome is in https://github.com/GoogleChromeLabs/chromium-bidi which is similarly to chromedriver is a CDP-client but written in TypeScript so it's a bit easier (subjective) to change. The permissions spec could be an example that implements both protocols https://www.w3.org/TR/permissions/#automation-webdriver-bidi