<scribe> ScribeNick: Florian

<kmag3> "You're not allowed to join this video call"

:(

I just get a "please wait..." message that never ends

I'll try to start a new one

<mikepie> Thanks

<mikepie> I was having trouble too

agenda

Florian: Anything to add?

mikepie: no

kmag3: more discussion about browserext protocol, and randomized IDs

browserext protocol ID

kmag3: at the moment, the IDs we use in firefox are always randomized
... but we haven't decided what to do with the browserext protocol

mikepie: we have not look at randomized IDs yet, but I can into it if you've got a specific proposal
... but 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 promisses, 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 http://www.w3.org/2017/02/02-browserext-minutes.html#action01]

Status update and issue resolution on https://browserext.github.io/browserext/

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: what are resolution labels about in github again?

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

mikepie: issue number 14 in github does talk about random IDs. we'll look into it later
... #15 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

Florian: not critical. The otherway around is annoying, when instructions to to authors or implementors are not clear if they're optional or not, it's annoying. Also when it is not clear who is supposed to be responsible for a must.

mikepie: Ok

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

mikepie: if you're ok, I'll do the merge, but we can keep the issue open

Florian: go ahead.

<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
... merge issue 15

<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 leaving it open for now

<mikepie> https://github.com/browserext/browserext/issues/21

mikepie: #21 is about whether strings accept null

kmag3: not sure what this is about. We talked about a JSON api availibility repo, 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

kmag3: the later

Florian: is this based on what would be good, or on compat with chrome?

<mikepie> https://github.com/browserext/browserext/issues/23

kmag3: compat.

RESOLUTION: merge issue 21

mikepie: #23: 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 http://www.w3.org/2017/02/02-browserext-minutes.html#action02]

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: #24 is 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: #34 I've added a few commands for installing/uninstalling extensions after the browser 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 to uninstall, similarly with an error code when that fails
... I 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.
... 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 added 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 http://www.w3.org/2017/02/02-browserext-minutes.html#action03]

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 dinstinguish between the two, and keep ping

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

scottlow: ????

kmag3: we do.

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
... also wondering about a separate one for beacon, or if ping is OK

kmag3: not strong opinion

RESOLUTION: add fetch, keep ping

<scribe> ACTION: kmag3 to check with mozilla engineers about beacon [recorded in http://www.w3.org/2017/02/02-browserext-minutes.html#action04]

rescheduling

Florian: current time is ideal for me, an hours 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.

This is scribe.perl Revision: 1.148  of Date: 2016/10/11 12:55:14  
Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/

Guessing input format: RRSAgent_Text_Format (score 1.00)

Succeeded: s/mikepie/scottlow/
Found ScribeNick: Florian
Inferring Scribes: Florian
Present: arybka mikepie scottlow kmag3 Florian
Agenda: https://lists.w3.org/Archives/Public/public-browserext/2017Feb/0000.html
Got date from IRC log name: 02 Feb 2017
Guessing minutes URL: http://www.w3.org/2017/02/02-browserext-minutes.html
People with action items: kmag3 mikepie scottlow

WARNING: Input appears to use implicit continuation lines.
You may need the "-implicitContinuations" option.