WebDriver/Meetings/2018-11-26

From MozillaWiki
Jump to: navigation, search

Agenda

  • Action item followup
    • Create deprecation document for Marionette client (ato)
    • File bug for document.hidden in headless mode (ato)
  • All-hands
  • CDP experiment update
  • Intermittents update

Minutes

Action item followup

ato
I haven’t done any of the action items, but will see if I get time next week.
AutomatedTester
I raised a needinfo for you on 1507372 but I don’t think this is realted to document.hidden.
Nevertheless it would be good if you could have a look so we get it classified directly.
It seems to be related to only headless, but I can’t tell if it’s a bug in headless—like your action item—or if it is simply a regression from your window manipulation changes.
ato
Will do.
And as I will explain shortly, there is another reason I haven’t had time to look at any actions, or indeed many needinfos, these past weeks…

All hands

ato
Who’s going to the all hands?
AutomatedTester
Just myself, mbrandt, and Kimerley.
ato
And jgraham.
jgraham
Yes.

CDP experiment update

The following is a rough summary of the discussion topic on the Chrome Debugging Protocol (CDP). The discussion was too fast-paced to be minuted.

ato
Two weeks ago I was given the opportunity by AutomatedTester to conduct an experiment on whether it is feasible to implement the Chrome Debugging Protocol, known as CDP, natively in Firefox.
In the past ten days I have spent most of my time writing a proof-of-concept implementation of the CDP protocol for Firefox.
The aim of the experiment has been multi-fold.
The primary objective has been to gain a deeper understanding of how CDP works, in order to inform future decisions on Puppeteer support for Firefox.
A secondary objective has been to experiment with what a Firefox-native implementation of it would look like, and if the semantics of CDP would lend themselves to Firefox.
Thirdly it has been to evaluate Juggler, which is the code drop we received from Google, which implements a new remote protocol in Gecko for use with a new backend to Puppeteer.
The current state of things is that I have an MVP that adds native CDP protocol support to Firefox, written as an XPCOM JS component.
It serves an HTTPD exposing the bare necessecities for the chrome-debugger-interface Node.js library to discover targets.
It spins up WebSockets for debuggers to connect to these targets, and messages over sockets are being despatched to the correct domain implemenations internally.
I’ve written enough plumbing to allow domains to relay messages to the content browser, wait for responses asynchronously, and emit events that come back.
The communication with frame scripts happen via actors, much inspired by devtools and the work kmag has done.
The ChildActor system used elsewhere in Firefox doesn’t quite work with this model for technical reasons to do with when they are installed, but practically speaking my custom implementation of them achieve the same effect.
The actor system lets you have a single content frame script with an IPC message listener that lets you load and unload JSMs into the child process.
I have started implementing the Page domain’s navigation methods and DOM events.
This is not quite working yet, but I can say with a reasonably amount of confidence that it is do-able to implement this in Firefox.
One of the discoveries I made working on this is, when comparing it to Juggler, is how similar they are in the implementation of the semantics and the API.
And also how much code they share: I have found traces of devtools code and of Marionette in Juggler.
Juggler was presented as a new remote protocol in Firefox specifically tailored to meet the demands of one product: Puppeteer.
I think a better presentation of Juggler, now that I have looked at it more in detail, is that it’s an implementation of CDP in Firefox, using the Firefox devtools remote protocol as the transport layer.
It would’ve caused less confusion and surprise if Juggler had been presented as a CDP implementation with a slightly different transport layer, than as a brand new remote protocol for a Node.js library…
In any case, I need to revise my earlier statements about Juggler and say instead that it is showing great promise and I think it is possible to reuse a lot of their domain implementation code in this experiment.
AutomatedTester
This sounds promising.
Are you able to show a demo? Does it work with Puppeteer directly?
ato
No, I haven’t yet completely implemented any of the domains.
Also, I understand Puppeteer makes use of the experimental Target domain which basically multiplexes any WebSocket object to the appropriate target, instead of forcing you to open a separate WebSocket connection to each debugging target.
Before I can implement that, I need something to multiplex to, which first means implementing Page.
jgraham
What things should you focus on to achieve a demo equivalent to Juggler?
AutomatedTester
Focussing on page navigation and DOM events sounds good.
jgraham
I also wonder about script execution.
ato
Script execution is unknown to me, but I can give it a try. It might be more complexity.
Certainly navigation and DOM script execution is do-able within the short term.
AutomatedTester
Is it possible to have a demo ready for Wednesday next week that I can show to Product?
ato
Maybe. I hope so.

[A discussion about Fission, and its impact on Marionette followed.] [Discussion about future maintainance of Marionette, given the context of CDP.]

AutomatedTester
Is it possible to retrofit the Marionette protocol on top of CDP?
ato
Yes, I remember you asked me to look into this.
I believe it is.

[Discussion about how to handle long-running WebDriver primitives in CDP, and whether geckodriver at some future point could be moved over from Marionette to CDP.]

[Discussion about process changes, and how they affect Chrome and Firefox, respectively.]

Status updates

(Spoken status updates in bold.)

PTO/travel (🍂)