WebDriver/Meetings/2019-01-14

From MozillaWiki
Jump to: navigation, search

Agenda

  • Python client deprecation
    • Do we announce discontinuing marionette_driver + marionette_harness on PyPI?
  • Fission

Minutes

Python client deprecation

ato
We are attempting to get rid of the Marionette Python client and the harness.
Comments on the deprecation plan were mostly positive.
Not much traction until we will know about a replacement.
For obvious reasons we can’t remove the in-tree marionette_driver and marionette_harness packages.
But should I announce that we are going to stop publishing to PyPI?
AutomatedTester
WebPageTest is a high profile out of tree user of Marionette.
We should try to coordinate with them which bits and bytes are missing, if any, from other clients.
Find out what is preventing them to move to a stock WebDriver client?
ato
There is no rush for us in deprecating it.
Maybe do it within six months?
AutomatedTester
Maybe start with three months and if people complain we can push it out to six months?
whimboo
I would suggest that we wait for the next ESR release which will be 67, released 15 May.
Then starting with 68 we wouldn’t release any new packages to PyPI.
People could still clone central and build on their own.
ato
jgraham at least metioned doing that for WPT.
I think it makes sense.
We will also do one final release of marionette_driver and marionette_harness so that at least the most recent code is available in the last package.

ACTION: ato to annonuce that we will stop making PyPI relases of marionette_driver and marionette_harness after the Firefox 67 ESR release.

Fission

ato
Navigation is a good example for talking about Fission.
There is a preference you can simulate how Fission would work in the future.
Talked to nika, and the actor system is not finalised yet and can/will be changed.
The code for frame script has to be written so that anything can be blown away at any time.
With Fission, each sub-frame (or nested browsing context) might potentially live in a separate process.
If you enable Fission simulation it is not possible to navigate the doctree and access frames.
Marionette currently expects calls to the frame script to be blocking and synchronous.
It uses a promise that is resolved when the frame script returns a matching message.
We cannot make this assumption with Fission, as the content browser is more likely to undergo remoteness changes when navigating.
whimboo
Other commands can also suffer unexpected remoteness changes.
I noticed this with the Find Element command recently.
How do we handle cases where driver.js is waiting for a reply from listener.js, but the reply never comes?
ato
The IPC message manager does not define a request/response system.
It’s literally just messages.
So anything to do with waiting for, and replying to requests from chrome space, is currently encoded in Marionette, c.f. proxy.js.
E.g. we should probably not handle the full action chain in the content process because any action could trigger a remoteness change.
Maybe we should refactor it so that primitives get sent one by one.
One novel aspect of the new child actor system is that DOM events, IPC message listeners, and system observers get automatically re-attached when the actor reloads.
whimboo
Important would be the data consistency and maybe we would have to find a way to force a remoteness change to test how it works.
ato
Other nice features is that Fission will let us do a better architecture with smaller commands.
AutomatedTester
Any idea when the documentation will be finished?
ato
There is already some documentation available.
https://searchfox.org/mozilla-central/source/toolkit/modules/ActorManagerParent.jsm#7
What seems to be missing is a high level overview.
AutomatedTester
DOM team asked us when we will be able to start working on Marionette, and what we would have to change.
ato
It's difficult to answer this high level question.
Moving Marionette to use the actor system would be a lot of work.
No changes seem to be necessary for test harnesses using Marionette to install extensions e.g. mochitest, reftest, wpt.
This relates to the CDP discussion, but I don’t know if this is the right forum to discuss that.
AutomatedTester
But do we have any grasp of what work is involved to make Marionette Fission-compatible?
ato
We handle remoteness changes for document navigation fairly well.
Better than, say, devtools.
The one, big problematic area will be frames.
If you want to support that you need the refactroing to the actor system otherwise we will lose support for frames.
Right now listener.js would be loaded in each frame, but we have lots of state to set up and we don’t always set that up consistently.
With fission the actors are registered automatically which is similar to manual way what we do in the registerSelf() method in listener.js.
Marionette might be at risk when it comes to full Fission support.
Again it’s a question how CDP plays in here.
AutomatedTester
I would like to not duplicate work but if things have to be done let do it and explain the additional costs doing it.
It would be good to find a balance and make people happy.
ato
So there’s an amount of work that needs to happen, somewhere, to make Marionette Fission compatible.
The question is if the work on CDP will duplicate some of that work.
We need the same sort of primitives for navigation and listening for DOM content events in CDP, as Marionette needs for doing some of the things it needs to do.
So I think my preferred battleplan would be to build out the transport layer of the new remote agent to a sufficient level, so that we can begin porting over Marionette features to a “WebDriver domain” in that.
Then we can flip geckodriver over to use this new domain and bring it up to parity with the existing Marionette protocol.
Eventually when they reach parity, we switch off the Marionette protocol.

Intermittents update (whimboo)

  • The support for the "New Window" in Marionette command relanded
    • 5 intermittent failures have been fixed which were caused by not being able to open a new tab
    • [fixed] Hang in TestNavigate.test_set_location_through_execute_script (Bug 1512336). Note that all commands beside navigation commands can hang if an unexpected remoteness change occurs (Bug 1519354)
  • Regressions from window manipulation changes
    • [fixed] Substantial delay when minimizing a window has been fixed (Bug 1507067)
    • [needs review] "WebDriver:SetWindowRect" throws invalid TimeoutError if window is resized to a not reachable dimension (Bug 1478358)
    • [investigation] "WebDriver:FullscreenWindow" throws invalid TimeoutError (Bug 1519777)
  • 2 Perma Android failures caused by landing the recent RefTest change + unit tests (Bug 1519614, Bug 1519552)
    • Both happen on a Tier2 platform and as such haven't been backed out
    • Should we change Marionette Android tests (at least opt) to Tier1?
  • Re-enabled tests
    • [marionette] Re-enable test TestNavigate.test_type_to_non_remote_tab (Bug 1369923)
    • [marionette] Re-enable TestNavigate.test_about_blank_for_new_docshell on Android (Bug 1334095)
    • [marionette] Re-enable test TestPageLoadStrategy.test_strategy_after_remoteness_change (Bug 1422741)

Status updates

(Spoken status updates in bold.)

  • whimboo
    • Triage of disabled tests in the Marionette and geckodriver components
    • Triage of old open issues for geckodriver on github
    • [spec] Rename "Create Window" command to "New Window" (#1392)
    • [spec] Fixed error types for "invalid argument" for frame id (#138, #1390)
    • [wdspec] Invalid frame id doesn't cause a "no such frame" error to be raised (Bug 1517196)
    • [marionette] Re-enable test TestNavigate.test_type_to_non_remote_tab (Bug 1369923)
    • [marionette] Re-enable test TestPageLoadStrategy.test_strategy_after_remoteness_change (Bug 1422741)
    • [marionette] Finally landed the support of the "New Window" command (Bug 1504756)
    • [marionette] "WebDriver:MinimizeWindow" has a substantial delay since bug 1492499 landed (Bug 1507067)
    • [marionette] "WebDriver:SetWindowRect" throws invalid TimeoutError if window is resized to a not reachable dimension (Bug 1478358)
    • [marionette] Remove dependency to cssTransform.html and cssTransform2.html in test_visibility.py (Bug 1441437)
  • ato
    • Fixed an incorrect reference to Marionette in the geckodriver documentation (1519869)
    • Drafted deprecation announcement for the Python client and harness
    • Did some geckodriver triage
    • Picked up the patch for fixing WebDriver:TakeScreenshot’s default dimensions (1385706)
    • CDP work, unrelated to this project

PTO/travel (⛄️)

  • ato away Thursday 17 January
Retrieved from "https://wiki.mozilla.org/index.php?title=WebDriver/Meetings/2019-01-14&oldid=1206210"