Open Bug 1518468 (marionette-fission) Opened 8 months ago Updated 7 days ago

[meta] Make Marionette fission compatible


(Testing :: Marionette, task)

Version 3
Not set


(Not tracked)


(Reporter: automatedtester, Unassigned)


(Depends on 8 open bugs, Blocks 2 open bugs)


(Keywords: meta)

This bug will track the work that needs to be done to make Marionette Fission compatible.

Mike or Felipe, are there some guidelines out there already which explain what to look out for to get fission compatible code landed, and which no-goes to avoid? For new code in Marionette which gets currently landed we would like to try to be compatible even we don't have fission support added. It should prevent us from having not to refactor lots of code later again. Thanks.

Flags: needinfo?(mconley)
Flags: needinfo?(felipc)

I'm working on documentation about it right now.. It'll be done in about a day or two and I'll let you know where it ends up (probably in the wiki)

Flags: needinfo?(mconley)
Flags: needinfo?(felipc)

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?

At the moment we should keep the CDP stuff and the fission work for Marionette separate and if there are opportunities to combine then do it. The problem with moving over to a new transport layer is the backwards compatibility we would need to maintain. We can discuss this further in the WebDriver meeting on Monday

Type: enhancement → task
Summary: [Meta] Make Marionette fission compatible → [meta] Make Marionette fission compatible
Depends on: 1499845
Depends on: 1555701
Depends on: 1555704
Depends on: 1559592
Depends on: 1519335
Depends on: 1565183

Documentation is now available:
Feedback is welcome if there is anything missing.

No longer depends on: 1499845
Depends on: 1572086
Depends on: 1572093
Depends on: 1574508
You need to log in before you can comment on or make changes to this bug.