As we are adding a new, third, CDP-based remote protocol to Gecko
we need a plan what to do with Marionette. Do we think it is still
reasonable to maintain two, largely competing, remote protocols?
The reason I ask this is that it’s abundantly clear we have a lot
of work to on Marionette to get it into a Fission-compatible state.
We also need to do that work on new code that we write for the new
remote agent. I believe there’s an overlap between the things
Marionette needs for Fission compatibility and the things we need
to write in order to support CDP.
My preferred short-term plan would be to port the WebDriver service
in Marionette to the new remote agent as a separate domain, and
have it internally rely on the same primitives as the other CDP
domains (Page, Runtime, et al.). This would encourage code reuse
and would avoid potential duplication of work on getting Marionette
in its current state Fission-ready. A longer term plan might be
for geckodriver to implement WebDriver on top of CDP (like chromedriver
does), but that seems more unrealistic given our current restrictions
as much more code would need to be written from scratch in Rust.
There are some unresolved questions about this plan related to
introducing a blocking API (WebDriver) on top of an essentially
non-blocking API such as CDP. It’s also a concern that if we
introduce a blocking WebDriver service, what would this mean if
WebDriver wanted to upgrade to CDP?