WebDriver/RemoteProtocol/Meetings/2019/03/11

Agenda

• Status update
• Google meeting
• Feature scoping
• Mailing list
• Intent-to-implement

Roster

Present

AutomatedTester, whimboo, sole, ato, yulia

Regrets

ochameau

Minutes

Status update

ato

The prototype has landed in central.

Got build peer review within seven minutes of flagging it! Now hooked up to the build system.

You’re able to check out m-c, add ac_add_options --enable-cdp to mozconfig.

This is temporary until we can make it build on Nightly-only, and we need to do this in order to run tests on TaskCluster.

Will look into this this week: to build in nightly only and not when official branding is enabled.

Don’t want to publish CDP in official builds yet.

Same approach as Marionette back in ye olde days.

In build but not beta or stable.

Do we need security review? Might be a good idea.

AutomatedTester

Yes even if they say it’s OK, don’t worry.

No rush because not on by default.

ato

I propose we turn it on for Nightly or we can’t run tests.

More of build peer matter than security matter.

AutomatedTester

It increases security surface, anything that exposes a new flag and a TCP port.

Will look at that for you.

Process for security assurance: https://mana.mozilla.org/wiki/pages/viewpage.action?pageId=66653753

ato

I will prepare patches anyway.

jgraham offered to help standing up TaskCluster jobs.

Idea to import Puppeteer tests and run them on tier-3 or something.

whimboo

Will these jobs be part of WPT?

[something Node.js dependency]

ato

They will be a separate TC job that simply shells out to Node.js and runs the imported Puppeteer test suite, I imagine.

Although since we have a long-term ambition to write a specification text of some sort for CDP, my hope is that we will eventually have conformance tests in WPT.

To continue with the status update…

After proto landed I got 13 patches from Alex.

He’d done some work on making it more Puppeteer friendly.

Implemented subsets of Target domain and Browser domain to get Puppeteer started.

Haven’t run Puppeteer against it yet, but looks promisng.

He also started implementing sessions.

Sessions in CDP are required so we can multiplex multiple commands over the Target domain.

I’ve found they are quite difficult to wrap your head around.

We could do with documenting them better.

Feature scoping

ato

Didn’t have time to feature scope.

However, I will file bugs for the basic commands that are a missing that we know we will need.

yulia

Actually, Alex and I did some work on this last week:

https://docs.google.com/document/d/1hEh2VswY0lT7oXG5eHRVedXZ55ll5SRLrs9WJtbOirE/edit

Two of these tasks have landed already!

Alex started a patch for opening in a tab.

I’ll be gone next week for some time.

Alex will come back to his aptch later, and I estimate it will land some time in April.

When it comes to how we scope features, we found that it was good to think of features as ‘tasks’ on a functional level.

For example, instead of talking about what commands or events to implement, it might make more sense to talk about implement the things necessary in order to achieve X.

Everything necessary for opening a tab first, then navigation and the events associated with it, &c.

ato

That makes a great deal of sense to me.

Thank you for looking at this, both of you.

Google meeting

yulia

Using meeting with Google to figure out how much they need for a presentation?

ato

Shouldn’t overthink the presentation.

Google has their own business priorities and we should respect that.

We were right that getting architecture design correct was the right choice.

Patches from Alex has shown that we can then rapidly add new things, regardless of which process things are in.

Need to be sure we don’t exhaust the resources in more fire drills.

yulia

I have notes for the meeting tomorrow.

I’ve also invited Jim Blandy as he has good internals knowledge.

Alex is not going to be there, but he sent me some questions:

Alex questions:

• Is there a good client library to use?
  • Chrome frontend and puppeteer do not share a common library.
  • chrome-remote-interface doesn't support sub-targets.
  • There is another one but this is less used/popular (typically, vs.code and debugger.html are using chrome-remote-interface).
  • Would it be worth contributing sessionID/sub-targets to chrome-remote-interface?
• Do you have plan to modify CDP to simplify puppeeteer implementation, like what you did with /json/version or changes to sub-target/Target domain tweaks?

yulia

Andrey had a lot of technical questions for us about Gecko.

They are at a stage where they are finishing their Juggler implementation, and need to make changes to Gecko.

The question is if we halt what we’re doing and help them out making those changes, or if we encourage them to go make the changes to Gecko themselves.

AutomatedTester

Whould align on roadmaps.

yulia

How specific?

AutomatedTester

Happy with vaguer, things will change.

Not this command, this command but… ‘this type of command’

yulia

Maybe more like ‘tasks you can do with Puppeteer’.

Although this might be parallelisable later on.

AutomatedTester

Showing “this is where we’re going” can help frame the conversation tomorrow.

yulia

They can also give us feedback based on their experience.

ato

Framing in terms of tasks is very sensible.

Some commands are very easy, others are very hard.

Returning to the question you had about whether we should halt our work and help Google finish their Juggler implementation, or if we should focus on porting Juggler functionality over to our remote agent.

My opinion is we shouldn’t hinder them from proposing changes, but if their work has proved anything it is they can get a good number of tests passing without modifying Gecko.

We should move as much code from Juggler into our remote agent as soon as possible.

I believe this will be more productive, than having to parallell implementations going on.

Maybe need to stop the work in Juggler and bring CDP work up to same parity level, and then work on just one thing.

But, of course, I suspect maybe Google has a different priority and will want to work towards a 100% pass rate.

We can’t do anything about that.

We’d rather get functionality into remote agent and work together in there.

We’re also not the topic experts for some of the questions they have about the Gecko changes.

yulia

Jim might be able to help.

Some of the changes they are proposing might even help DevTools.

I agree we shouldn’t pause our work, but some C++ changes might help.

This might be an interesting conversation.

ato

It seems they want a lot of tech details but we don’t necessarily know all of these.

Alex’ questions are more about CDP proto rather than the implementation, and maybe Andrey is not the right recipient for those questions?

From my side more about getting us together in a room and learn about what their goals, cooperation extent.

ato

Also regarding the intent to implement we need some note about what the standards situation is for this feature.

We don’t have a good answer to this right now.

Some developers might be concerned about this.

Intent-to-implement

yulia

Where does this requirement to inform about intent to implement come from?

ato

Actually ted said we don’t need to do this because it’s technically not a web feature.

It might just be us being nice.

I think it’s an option not to worry about this.

Maybe rephrase the intent to implement to an announcement that “we’ve done this work”.

yulia

Also we should highlight that we’re working on interoperability.

Don’t think that many people will have issues with that.

These CDP methods are focussed on the interoperability layer.

ato

I will rewrite this and then ask for feedback.

Mailing list

ato

We finally have a mailing list, and it’s public.

Called dev-remote.

It should get migrated with the rest of mailing lists to the new solution IT is working on.

We should our discussions from puppeteer-review to this new mailing list, as long as it’s publicly discussable.

PTO (🌷)

• ato away:
  • Thursday 14 March
  • Friday 15 March
  • Wednesday 20 March
  • Friday 22 March
  • Week of 25–29 March
• ochameau away until 18 March
• ystartsev away Monday 18 March – 12 April