[meta] Make Marionette Fission compatible
Categories
(Remote Protocol :: Marionette, task)
Tracking
(Fission Milestone:M7)
Fission Milestone | M7 |
People
(Reporter: automatedtester, Unassigned)
References
(Depends on 1 open bug, Blocks 1 open bug, )
Details
(Keywords: meta, Whiteboard: fission-tests)
This bug will track the work that needs to be done to make Marionette Fission compatible.
Comment 1•6 years ago
|
||
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.
Comment 2•6 years ago
|
||
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)
Comment 3•6 years ago
|
||
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?
Reporter | ||
Comment 4•6 years ago
|
||
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
Updated•5 years ago
|
Updated•5 years ago
|
Comment 5•5 years ago
|
||
Documentation is now available: https://firefox-source-docs.mozilla.org/dom/dom/Fission.html#js-window-actor
Feedback is welcome if there is anything missing.
Comment 6•5 years ago
•
|
||
Tracking for Fission milestone M6 because we want to be able to run Marionette tests with Fission before enabling in Nightly.
Updated•5 years ago
|
Updated•5 years ago
|
Comment 7•5 years ago
|
||
Tracking for Fission Nightly M6b because WPT depends on Marionette.
We'll eventually need to make WebDriver Fission-compatible to support third-party testing.
Comment 8•5 years ago
|
||
Please note that Maja and myself will start on Fission specific work for Marionette by early June.
Regarding test coverage, there is a handful wdspec tests that are affected by Fission. As noted in the switchToFrame bug, it's the only command with dedicated cross-origin tests.
As we make more commands Fission-compatible, we should extend/add corresponding wdspec tests over Marionette tests, when possible.
Comment 10•4 years ago
|
||
Yes, see also bug 1560181 that is about moving all content scope tests from Marionette unit tests to wdspec.
Updated•4 years ago
|
Comment 11•4 years ago
|
||
Meta bug for all Marionette-Fission should be beta blocking for Fission.
Comment 12•4 years ago
|
||
For the transition of all the WebDriver specific commands I created a spreadsheet for tracking, also we haven't filed all the bugs yet:
https://docs.google.com/spreadsheets/d/1jkTZavbUhuqhqUQX1XHYsr5yteNUGLa8avzF_GueB28/edit#gid=0
Updated•4 years ago
|
Comment 13•4 years ago
|
||
The work here is basically done. The necessary code removal for non-fission code (bug 1669172) doesn't impact any Fission compatibility.
Updated•2 years ago
|
Description
•