IRC log of browserext on 2017-02-02

Timestamps are in UTC.

02:25:51 [RRSAgent]
RRSAgent has joined #browserext
02:25:51 [RRSAgent]
logging to http://www.w3.org/2017/02/02-browserext-irc
02:26:02 [Zakim]
Zakim has joined #browserext
02:26:12 [Florian]
Meeting: Browser Extension CG teleconf
02:26:22 [Florian]
ScribeNick: Florian
02:26:27 [Florian]
Chair: Florian
02:26:51 [Florian]
Agenda: https://lists.w3.org/Archives/Public/public-browserext/2017Feb/0000.html
02:26:57 [kmag3]
kmag3 has joined #browserext
02:29:09 [mikepie]
mikepie has joined #browserext
02:30:56 [kmag3]
"You're not allowed to join this video call"
02:31:03 [Florian]
:(
02:31:20 [Florian]
I just get a "please wait..." message that never ends
02:31:26 [Florian]
I'll try to start a new one
02:32:03 [mikepie]
Thanks
02:32:08 [mikepie]
I was having trouble too
02:34:46 [Florian]
TOPIC: agenda
02:34:53 [Florian]
Florian: Anything to add?
02:35:05 [Florian]
mikepie: no
02:35:14 [arybka]
arybka has joined #browserext
02:36:15 [Florian]
kmag3: more discussion about browserext protocol, and randomized IDs
02:37:13 [Florian]
TOPIC: browserext protocol ID
02:37:27 [Florian]
kmag3: at the moment, the IDs we use in firefox are always randomized
02:38:02 [Florian]
kmag3: but we haven't decided what to do with the browserext protocol
02:38:34 [Florian]
mikepie: we have not look at randomized IDs yet, but I can into it if you've got a specific proposal
02:39:17 [Florian]
mikepie: but as far as the standardized scheme goes, we don't think the cost/benefit makes it worth doing.
02:39:39 [Florian]
mikepie: We realize that doing it early has benefits, but even then, not interested for now.
02:39:55 [Florian]
mikepie: For promisses, we do agree that it makes sense and are going that way.
02:40:15 [Florian]
mikepie: I haven't thought about the implications of randomized IDs, can you explain more?
02:40:52 [Florian]
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
02:41:01 [Florian]
mikepie: what about when you want to talk to the extension?
02:41:24 [Florian]
kmag3: we use an internal ID for that, for instance for messaging, but that's unrelated to the one we use in URLs
02:41:40 [Florian]
arybka: it makes sense from a security standpoint
02:41:51 [Florian]
kmag3: that's the consensus from our security people
02:42:17 [Florian]
ACTION: mikepie and scottlow to look into randomized IDs
02:42:22 [Florian]
TOPIC: Status update and issue resolution on https://browserext.github.io/browserext/
02:43:45 [Florian]
mikepie: I don't think the randomized ID issue is tracked, so I'll make one. Let's go through the rest.
02:44:00 [Florian]
mikepie: how about we start with the webdriver issues (33, 34) first?
02:45:50 [Florian]
mike: what are resolution labels about in github again?
02:46:20 [Florian]
Florian: for recording decisions made on the the call. If you're closing an issue the old fashioned way, just close it.
02:47:43 [Florian]
mikepie: issue number 14 in github does talk about random IDs. we'll look into it later
02:48:18 [Florian]
mikepie: #15 about must /may / should: I made some changes relating to this
02:48:37 [Florian]
mikepie: I was about to suggest we punt, but maybe you can help me actually
02:49:22 [Florian]
mikepie: I've added a few mays and a few musts, and we now have definitions for everything described in the IDL
02:49:58 [Florian]
mikepie: I introduced these from MDN, but that added a whole lot of mays, which I am not sure are used right
02:50:40 [Florian]
Florian: what are they used for?
02:51:57 [Florian]
mikepie: descriptions
02:53:19 [Florian]
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.
02:53:28 [Florian]
mikepie: Ok
02:53:54 [Florian]
Florian: are you waiting for merging this, or is it merged already?
02:54:13 [Florian]
mikepie: if you're ok, I'll do the merge, but we can keep the issue open
02:54:56 [Florian]
Florian: go ahead.
02:55:26 [mikepie]
https://github.com/browserext/browserext/issues/16
02:55:47 [Florian]
mikepie: This one is about normative vs informative statements
02:56:20 [Florian]
mikepie: they were initially all wrong due to copy paste, but I've gone through and adjusted all that, so it should be good now.
02:56:47 [Florian]
Florian: I think we should merge this as well.
02:57:06 [Florian]
RESOLUTION: merge issue 16
02:57:08 [Florian]
RESOLUTION: merge issue 15
02:57:31 [mikepie]
https://github.com/browserext/browserext/issues/18
02:58:14 [Florian]
mikepie: this one is about adding an informative section on interaction with the CSP
02:58:30 [Florian]
mikepie: there's also a general section further down about the CSP
02:58:43 [Florian]
kmag3: I think the new one should move down
02:59:10 [Florian]
kmag3: and also we should specify the CSP restriction as a CSP policy string
02:59:24 [Florian]
arybka: +1
02:59:54 [Florian]
Florian: do you have all you need to address this?
02:59:56 [Florian]
mikepie: yes
03:00:10 [Florian]
mikepie: so leaving it open for now
03:00:20 [mikepie]
https://github.com/browserext/browserext/issues/21
03:00:28 [Florian]
mikepie: #21 is about whether strings accept null
03:01:47 [Florian]
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.
03:02:06 [Florian]
mikepie: I followed what MDN has to say, and accepted NULL when it said things are optional
03:02:13 [Florian]
kmag3: this is generated form the JSON
03:03:24 [Florian]
Florian: is this JSON informative, or used to generate the bindings
03:03:28 [Florian]
kmag3: the later
03:04:15 [Florian]
Florian: is this based on what would be good, or on compat with chrome?
03:04:18 [mikepie]
https://github.com/browserext/browserext/issues/23
03:04:20 [Florian]
kmag3: compat.
03:05:22 [Florian]
RESOLUTION: merge issue 21
03:06:09 [Florian]
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.
03:06:47 [Florian]
kmag3: I think the text about IDs should not go into the manifest, as it is not specific to it
03:07:01 [Florian]
mikepie: should we not have it, or have it in a separate section?
03:07:18 [Florian]
kmag3: separate section, to avoid misleading people into thinking it's only available in the manifest
03:08:15 [Florian]
ACTION: mikepie to move section about predefined localization messages out of the manifest section
03:09:09 [Florian]
mikepie: can I take the pull request, and then move out the section?
03:09:11 [Florian]
kmag3: yes
03:09:43 [Florian]
RESOLUTION: merge issue 23, then move part to separate section
03:10:55 [Florian]
mikepie: #24 is the one about a separate section for predefined messages
03:11:50 [Florian]
mikepie: there are more things to go through, but I'd like to talk about web driver first
03:12:08 [Florian]
mikepie: also, scottlow has a proposal about web requests
03:12:58 [Florian]
mikepie: 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
03:13:30 [Florian]
scottlow: #34 I've added a few commands for installing/uninstalling extensions after the browser launched
03:14:16 [Florian]
scottlow: I added a POST to /sessions/{id}/browserext
03:14:37 [Florian]
scottlow: that's the way sessions are created in webdriver
03:14:58 [Florian]
scottlow: also added an error code for when the installation fails, maybe due to problems in the manifest
03:15:44 [Florian]
Florian: do we want to discriminate on why installation is failing?
03:16:11 [Florian]
kmag3: I'd rather leave the details out of the API. Otherwise, people may end up depending on implementation specific details
03:17:01 [Florian]
scottlow: the next command is the one to uninstall. Using a DELETE command to uninstall, similarly with an error code when that fails
03:17:32 [Florian]
scottlow: I made some changes to how takeBrowserExtAction
03:18:08 [Florian]
scottlow: instead of having numerical ids that people need to lookup, we thought that using strings was less error prone and open ended
03:18:31 [Florian]
Florian: yeah, numeric IDs are terrible for extensibility
03:18:48 [Florian]
scottlow: the JSON object just gets a type parameter, with any one of these.
03:19:05 [Florian]
scottlow: I think that sums up the dynamic install/uninstall part.
03:20:04 [Florian]
Florian: is this a PR you want to merge, or have you already?
03:20:26 [Florian]
scottlow: this is PR 43.
03:20:39 [Florian]
kmag3: I'd be happy with merging it now
03:20:47 [Florian]
RESOLUTION: merge PR 43
03:21:15 [Florian]
mikepie: issue #33 is for context menus, kmag3 added other things like separators, checkboxes, so these were added.
03:21:33 [Florian]
mikepie: I think that's all there was to it.
03:22:23 [Florian]
mikepie: 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
03:22:45 [Florian]
mikepie: kmag3 can you have a look at that section, check if I missed something
03:23:10 [Florian]
ACTION: kmag3 to check if anything is missing from the context menu section
03:23:21 [Florian]
kmag3: I think we discussed making it a POST request
03:23:45 [Florian]
kmag3: we also discussed changing its name
03:23:58 [Florian]
mikepie: will do.
03:25:09 [Florian]
mikepie: issue 45: I'd like to get feedback: do we want to distinguish between xmlhttprequest and fetch?
03:25:26 [Florian]
s/mikepie/scottlow/
03:25:50 [Florian]
scottlow: I think google was moving that way, but is getting some backlash
03:26:14 [Florian]
scottlow: I think we should dinstinguish between the two, and keep ping
03:26:35 [Florian]
kmag3: we have it separately internally, not sure about the API.
03:26:42 [Florian]
scottlow: ????
03:26:45 [Florian]
kmag3: we do.
03:28:40 [Florian]
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.
03:28:57 [Florian]
scottlow: we're thinking of keeping ping as a separate thing
03:29:15 [Florian]
scottlow: also wondering about a separate one for beacon, or if ping is OK
03:29:22 [Florian]
kmag3: not strong opinion
03:29:51 [Florian]
RESOLUTION: add fetch, keep ping
03:30:07 [Florian]
ACTION: kmag3 to check with mozilla engineers about beacon
03:31:36 [Florian]
TOPIC: rescheduling
03:32:20 [Florian]
Florian: current time is ideal for me, an hours early works too.
03:32:39 [Florian]
kmag3: this or earlier is equally good
03:32:46 [Florian]
arybka: earlier would be nicer
03:33:02 [Florian]
mikepie: how about 1h earlier?
03:33:08 [Florian]
all: yes
03:33:39 [Florian]
mikepie: How about 2 weeks from now, on the 15th, 5:30pm PST?
03:33:51 [Florian]
all: yes.
03:34:35 [Florian]
Present: arybka, mikepie, scottlow, kmag3, Florian
03:34:42 [Florian]
RRSAgent, make log public
03:34:51 [Florian]
RRSAgent, draft minutes
03:34:51 [RRSAgent]
I have made the request to generate http://www.w3.org/2017/02/02-browserext-minutes.html Florian
03:35:20 [Florian]
RRSAgent, bye
03:35:20 [RRSAgent]
I see 4 open action items saved in http://www.w3.org/2017/02/02-browserext-actions.rdf :
03:35:20 [RRSAgent]
ACTION: mikepie and scottlow to look into randomized IDs [1]
03:35:20 [RRSAgent]
recorded in http://www.w3.org/2017/02/02-browserext-irc#T02-42-17
03:35:20 [RRSAgent]
ACTION: mikepie to move section about predefined localization messages out of the manifest section [2]
03:35:20 [RRSAgent]
recorded in http://www.w3.org/2017/02/02-browserext-irc#T03-08-15
03:35:20 [RRSAgent]
ACTION: kmag3 to check if anything is missing from the context menu section [3]
03:35:20 [RRSAgent]
recorded in http://www.w3.org/2017/02/02-browserext-irc#T03-23-10
03:35:20 [RRSAgent]
ACTION: kmag3 to check with mozilla engineers about beacon [4]
03:35:20 [RRSAgent]
recorded in http://www.w3.org/2017/02/02-browserext-irc#T03-30-07