From MozillaWiki
Jump to: navigation, search


  • Status update on prototype
  • Real-time communication channel
    • Slack/IRC?
  • Mailing list
  • Intent-to-implement
  • Next meeting


AutomatedTester, ochameau, yulia, sole, ato


Status update

Let’s start with the positives.
I have been able to fix the worries we had with the HTTPD, and it can now serve WebSocket connections off the same server.
It required some nasty hacks to repurpose the underlying socket connection, and I haven’t tested if it can support multiple connections yet, but it works reasonably well for now.
This means there are no show-stoppers left that we know about.
We originally listed deduplicating EventEmitter.jsm as a hard requirement for shipping this, but I’m starting to think we can file a bug and address this afterwards.
I agree.
We got slightly derailed last week, but we’re on track of landing the prototype in central this week.
One question, though: I know ochameau had some local code lying around he has not landed yet?
I’m trying to set us up so we can run Puppeteer with a simple, näive script.
Preliminary work on getting Puppeteer working without running any domain commands.
There are some small differences to what we’ve done so far, because they’re not using the npm package chrome-remote-interface we have been working against.
I was convinced they were using that, because nearly everyone—including VSCode—uses it.
I tried to figure out why they’re not using chrome-remote-interface, but I couldn’t find any good explanation.
Apparently Puppeteer doesn’t even clone the Chrome frontend client.
So this means they’ve written their own.
The only downside to this is that I thought we were going to be using chrome-remote-interface for writing the tests.
It’s an obvious choice because it runs in web content, which means we can run it as a browser-chrome test.
If we want to support Puppeteer well, the best way is to actually run the Puppeteer client and its tests on TaskCluster as a separate job, where we shell out to Node.js.
I agree, but how confident are you that this code you’re working on will be ready for central?
The good news is that it doesn’t require any architectual work.
It implements parts of the Target domain for attaching automatically to targets.
Then it sounds like we made the right technical decisions regarding architecture when we started out, and I’m happy you didn’t have to go back and change it.
However, precisely because it builds on top of what we already have, does it make sense for us to punt this until after we’ve landed the initial prototype in central?
Your patch to the HTTP is more important, otherwise we won’t be compatible with anything.
My work will make it possible for us to then connect to Puppeteer, but it won’t work without the HTTP fix.
If we defer your patch, what is the timeline for getting the code into the tree?
I know you said “by end of last week” before, but we obviously missed that.
It largely depends on how quickly we can get a review from the build peers.
As ted suggested, the patch itself will ship with r=ochameau,ato.
But we still need r+ on the parts the interlink with the build system.
Then if I help out to get the build peers’ attention, we can land it by Wednesday?
I think that would be a reasonable estimate.
I will have the HTTP fix in by end of today.
Alex, it would be good if you could start the secondary cursory review now.

Real-time communication

I would prefer not using IRC because of the spam.
The one problem I see with Slack, is if we want to have a chat with Googlers, they can’t get onto Slack because of the NDA requirement.
Could we use the DevTools Slack?
Yes, the only problem is it’s not archived because it’s not a paid instance of Slack.
Can we have an invite-only channel on IRC?
The way we have solved this on certain IRC channels, is by setting a special mode that makes it impossible for unregistered users to join them.
This effectively addresses the spam problem.
Yes, infact there’s a special mode you can set that allows users to join a channel, but not speak until they register.
I think that makes more sense.
Do we worry about the channel being indexed?
I don’t think so.
People are already watching other channels for notifications, such as for bugs being fixed.
Do you have an opinion, Alex?
We’re all on IRC, so that seems like a reasonable option.

Mailing list

I’m still struggling to get the dev-remote mailing list created.
No one in IT seems to want to take responsibility for it, and it keeps getting transferred between different people.
I reached out to cshields last week and he told me that Mozilla is decommissioning Mailman and the NNTP [newsgroups] connection, and instead moving to Google Groups.
I have personal reservations against Google Groups because they are basically impossible to join without already having a Google account.
But I want our mailing list to live alongside dev-platform and firefox-dev, so I’m proceeding with this option.
cshields also mentioned Discourse as a possible alternative if we didn’t want Google Groups.
But I have had problems using the Mozilla Discourse server, for various admin reasons.
Trying to work those out, so it may be an option in the future.


There was also an intent-to-implement document.
What is the status of that? When are we sending it out?
I think that largely depends on what comes out of our afternoon meeting.
But I would like to get it out by end of this week, or possibly early next week.

Next meeting

This meeting returns to its normal schedule next week.
The reason we did it one hour later today was that we have an afternoon meeting, and I didn’t want to spend eight hours at work.
So next week’s meeting will be coming Monday at 09:00 GMT/10:00 CET.

PTO (🌷)

  • ochameau away Friday 8 March
  • ystartsev away Monday 18 March – 12 April