Browser Extension CG teleconf — 02 Feb 2017


See also: IRC log


Andrey Rybka (arybka), Mike Pietraszak (mikepie), Scott Low (scottlow), Kris Maglione (kmag3), Florian Rivoal (Florian)
Andrew Swan (aswan)


Extra Agenda Items

Florian: Anything to add to the agenda?

mikepie: Not from me.

kmag3: I'd like more discussion about browserext protocol, and randomized IDs.

Browserext Protocol & Ids

kmag3: At the moment, the ids we use in Firefox are always randomized but we haven't explicitly decided what to do with the browserext protocol.

mikepie: We have not looked at randomized ids yet, but I can look into it if you've got a specific proposal.
... As far as the standardized scheme goes, we don't think the cost/benefit makes it worth doing.
... We realize that doing it early has benefits, but even then, not interested for now.
... For promises, we do agree that it makes sense and are going that way.
... I haven't thought about the implications of randomized IDs, can you explain more?

kmag3: When the extension is installed we generate a new random id, and from there on that's the id that is used in the URL, for that specific installation.

mikepie: What about when you want to talk to the extension?

kmag3: We use an internal id for that, for instance for messaging, but that's unrelated to the one we use in URLs.

arybka: It makes sense from a security standpoint.

kmag3: That's the consensus from our security people.

<scribe> ACTION: mikepie and scottlow to look into randomized IDs [recorded in]

Status Update and Issue Resolution on

mikepie: I don't think the randomized ID issue is tracked, so I'll make one. Let's go through the rest.
... How about we start with the webdriver issues (33, 34) first?

mike: By the way, what are resolution labels about in Github again?

Florian: For recording decisions made on the call. If you're closing an issue the old fashioned way, just close it.

mikepie: Issue number 14 does talk about random IDs. We'll look into it later
... Issue #15 is about MUST / MAY / SHOULD. I made some changes relating to this.
... I was about to suggest we punt, but maybe you can help me actually.
... I've added a few MAYs and a few MUSTs, and we now have definitions for everything described in the IDL.
... I introduced these from MDN, but that added a whole lot of MAYs, which I am not sure are used right

Florian: What are they used for?

mikepie: Descriptions of the state of things, where it is possible that something could be in a certain state.

Florian: That's not critical. The other way around is annoying, when instructions to to authors or implementors are not clear if they're optional or not. Also a problem when you have a statement that “something must be such and such” when it is not clear who is supposed to be responsible for putting it in that state (authors, UAs...).
... Descriptive statements that (ab)use the MUST / SHOULD / MAY could be improved by rephrasing but they're not actually causing problems, so don't worry.

mikepie: Ok.

Florian: Are you waiting for merging this, or is it merged already?

mikepie: If you're OK with it, I'll do the merge, but we can keep the issue open.

Florian: go ahead.

RESOLUTION: Merge issue 15


mikepie: This one is about normative vs informative statements.
... They were initially all wrong due to copy&paste, but I've gone through and adjusted all that, so it should be good now.

Florian: I think we should merge this as well.

RESOLUTION: merge issue 16


mikepie: This one is about adding an informative section on interaction with the CSP.
... There's also a general section further down about the CSP.

kmag3: I think the new one should move down;
... and also we should specify the CSP restriction as a CSP policy string.

arybka: +1

Florian: Do you have all you need to address this?

mikepie: Yes, so I'll leave it open for now and deal with it later.


mikepie: This is about whether and where strings accept null

kmag3: I am not sure what this is about. We talked about using a JSON file that has info API availibility, but that doesn't include types. We have another source, I can send you a link.

mikepie: I followed what MDN has to say, and accepted NULL when it said things are optional.

kmag3: This is generated form the JSON.

Florian: Is this JSON informative, or used to generate the bindings in Firefox?

kmag3: The later, so it is authoritative.

Florian: Is this based on what would be good to do in theory, or on compat with Chrome?

kmag3: Compat.

RESOLUTION: merge issue 21


mikepie: This one I've already accepted the pull request, but I don't think we've talked through it. This is also heavily pulled form MDN.

kmag3: I think the text about ids should not go into the manifest, as it is not specific to it.

mikepie: Should we not have it, or have it in a separate section?

kmag3: Separate section, to avoid misleading people into thinking it's only available in the manifest.

<scribe> ACTION: mikepie to move section about predefined localization messages out of the manifest section [recorded in]

mikepie: can I take the pull request, and then move out the section?

kmag3: yes

RESOLUTION: merge issue 23, then move part to separate section

mikepie: Issue 24 is actually the one about a separate section for predefined messages.
... there are more things to go through, but I'd like to talk about web driver first
... Also, scottlow has a proposal about web requests
... kmag3 at TPAC, you had some good suggestions about how to deal with permission UI, so I'd like to check that with you, possibly over mail if you don't get the time today.

scottlow: Issue 34: I've added a few commands for installing/uninstalling extensions after the browser is launched.
... I added a POST to /sessions/{id}/browserext.
... That's the way sessions are created in webdriver.
... Also added an error code for when the installation fails, maybe due to problems in the manifest.

Florian: Do we want to discriminate on why installation is failing?

kmag3: I'd rather leave the details out of the API. Otherwise, people may end up depending on implementation specific details.

scottlow: The next command is the one to uninstall. Using a DELETE command for that, similarly with an error code when that fails.
... I also made some changes to how takeBrowserExtAction:
... instead of having numerical ids that people need to lookup, we thought that using strings was less error prone and open ended.

Florian: Yeah, numeric IDs are terrible for extensibility.

scottlow: The JSON object just gets a type parameter, with any one of these strings.
... I think that sums up the dynamic install/uninstall part.

Florian: is this a PR you want to merge, or have you already?

scottlow: This is PR 43.

kmag3: I'd be happy with merging it now

RESOLUTION: < href="">merge PR 43

mikepie: Issue #33 is for context menus. kmag3 asked for other things like separators, checkboxes, so these were added.
... I think that's all there was to it.
... It's been a while, so I am no longer sure. I think I added everything that we supported in our API for context menus.
... kmag3 can you have a look at that section, check if I missed something?

<scribe> ACTION: kmag3 to check if anything is missing from the context menu section [recorded in]

kmag3: I think we discussed making it a POST request.
... We also discussed changing its name.

mikepie: Will do.

scottlow: Issue 45: I'd like to get feedback: do we want to distinguish between xmlhttprequest and fetch?
... I think Google was moving that way, but is getting some backlash
... I think we should distinguish between the two, and keep ping

kmag3: We have it separately internally, not sure about the API.

scottlow: ????

Florian: I did not understand, can you explain a bit more?

mikepie: For web requests, there are these different types, and a proposal to make fetch a separate type, and another for ping. Google is lumping ping into xmlhttprequest.

scottlow: We're thinking of keeping ping as a separate thing.
... We are also wondering about a separate one for beacon, or if ping is OK for both.

kmag3: No strong opinion

RESOLUTION: add fetch, keep ping

<scribe> ACTION: kmag3 to check with mozilla engineers about beacon [recorded in]

Scheduling Next Meeting

Florian: Current time is ideal for me, an hour early works too.

kmag3: This or earlier is equally good.

arybka: Earlier would be nicer.

mikepie: How about 1h earlier?

all: Yes

mikepie: How about 2 weeks from now, on the 15th, 5:30pm PST?

all: Yes

Summary of Action Items

[NEW] ACTION: kmag3 to check if anything is missing from the context menu section
[NEW] ACTION: kmag3 to check with mozilla engineers about beacon
[NEW] ACTION: mikepie and scottlow to look into randomized IDs
[NEW] ACTION: mikepie to move section about predefined localization messages out of the manifest section

Summary of Resolutions

  1. merge issue 15
  2. merge issue 16
  3. merge issue 21
  4. merge issue 23, then move part to separate section
  5. merge PR 43
  6. add fetch, keep ping