Intent to ship: remote-protocol (CDP)

[James Graham]

Summary: remote-protocol provides a Firefox implementation of a subset
of the Chrome DevTools Protocol (CDP) [1], specifically targeted at
testing and automation use cases.

remote-protocol isn't a web-exposed feature so it doesn't fit into the
standard exposure guidelines. However we're mentioning it here to ensure
everyone is aware of our plans.

Libraries such as Puppeteer and Selenium 4 depend on CDP for
implementing browser automation with an API and featureset that isn't
possible using standardised WebDriver. These libraries have either been
Chrome-only or shipped a reduced featureset with Firefox, making it
harder for web authors to test their sites against Gecko.

In order to address this issue we have been shipping support for a
subset of CDP in Nightly Firefox for several releases under the name
"remote-protocol". It is the basis for the current Firefox support in
Puppeteer, and some Selenium 4 clients use it for preliminary Firefox
support.

We now want the remote-protocol support to ride the trains so that users
may test against stable Firefox. This is important, despite the fact the
implementation remains incomplete, because for web-app testing Nightly
is not a viable replacement for beta and stable due to the different
features enabled on each channel.

Note that activating the remote-protocol server requires a specific
command line flag, so for the majority of Firefox users this has no
impact (this is identical to the way the existing marionette server works).

CDP is not part of any web standard, and is not exposed to content. In
the long term we believe that the testing and automation use case should
be fully served by cross-browser standard features; for this reason we
have been working on webdriver-bidi [2], which will provide a
standardised replacement for this feature. However with automated test
tools increasingly using CDP instead of, or in addition to, WebDriver,
we need to meet users where they are while the standard matures.

More details of the current state of the test automation landscape, and
details of how to use the CDP support are in our hacks posts [3], [4].

Bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1606604
Standard: N/A but will eventually be replaced by [2]
Platform coverage: All
Preference: Behind a command line flag: --remote-debugging-port
DevTools bug: N/A
Other browsers: Blink-only. Other vendors are participating in the
WebDriver-BiDi standard.
web-platform-tests: N/A

[1] https://chromedevtools.github.io/devtools-protocol/
[2] https://w3c.github.io/webdriver-bidi/
[3]
https://hacks.mozilla.org/2020/12/cross-browser-testing-part-1-web-app-testing-today/
[4]
https://hacks.mozilla.org/2021/01/improving-cross-browser-testing-part-2-new-automation-features-in-firefox-nightly/

[Anne van Kesteren]

On Tue, Jan 12, 2021 at 5:43 PM James Graham <ja...@hoppipolla.co.uk> wrote:
> CDP is not part of any web standard, and is not exposed to content.

Seems unfortunate we cannot standardize on this format if we have to
support it anyway, but I guess that was already considered and found
not feasible?

[James Graham]

Yes, that was a definite point of consideration, but I don't think it
would work out to do it directly:

* There's no support from other vendors from standardizing CDP as-is.

* CDP exposes some blink internals that aren't reasonable to bake into a
cross-browser standard.

* Parts of CDP are awkward to use for automation use cases (this is
probably the weakest reason).

Having said that it's clear that the automation client ecosystem needs a
transition path away from CDP, and this means that the standard has to
be pretty close in terms of the semantics and feature set. The intent is
to work with clients through the standards process to ensure they're
able to support WebDriver-BiDi as a backend; if that becomes too
difficult it will be a red flag that we've done something that has a low
chance of succeeding.