See also: IRC log
Florian: Anything to add to the agenda?
mikepie: Not from me.
kmag3: I'd like more discussion about browserext protocol, and randomized 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 https://github.com/browserext/browserext/issues/14#issuecomment-276878008]
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> https://github.com/browserext/browserext/issues/16
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> https://github.com/browserext/browserext/issues/18
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> https://github.com/browserext/browserext/issues/21
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> https://github.com/browserext/browserext/issues/23
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 https://github.com/browserext/browserext/issues/24#issuecomment-276877702]
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: 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 https://github.com/browserext/browserext/issues/33#issuecomment-276877509]
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 https://github.com/browserext/browserext/issues/45#issuecomment-276881216]
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