Browser Extension CG teleconf — 09 Sep 2016

Agenda

See also: IRC log

Attendees

Present
Florian (Florian Rivoal), mikepie (Mike Pietraszak), kmag (Kris Maglione)
Regrets
Chair
Florian
Scribe
Florian

Contents


Agenda

Florian: Any other item you would like to add to the agenda?

mikepie: nope

TPAC

https://github.com/browserext/browserext.github.io/wiki/2016-TPAC-Agenda

Florian: This is a wikipage to prepare for TPAC;
... please add topics you want to discuss, and your name if you plan to attend.
... It should be publicly writteable

mikepie: Looks editable to me.

Liaison with Testing and Tools WG/WebDriver

mikepie: I will be able to attend the testing sessions on Monday / Tuesday as an observer.
... John Jansen from MS will there and able to represent us.
... We'll request that this topic be added when the chairs make a call for the agenda.

Florian: This hasn't been brought to that group yet, has it?

mikepie: Only as a side comment maybe.
... I'll check if the link I have is the latest version, and then add to our own agenda as well.

Florian: So we wait for feedback from that group before there is anything more to discuss here, right?

mikepie: Right.

https://github.com/browserext/browserext/pull/4

Florian: I've done a light review. I think it can be merged before my comments are addressed and then we track them individually, but if you want to fix them before, that's great too.

kmag: I'll review and send comments today.

mikepie: I try to follow the proposal around the web IDL, looking for feedback on that.
... There a huge hole: the callback functions aren't defined yet.

kmag: Might be a good topic for TPAC.

Florian: kmag, do you want merge-then-comment, or comment-fix-then-merge?

kmag: I'd like to comment first.

mikepie: Do we really need the extension object?
... Much of the APIs there that aren't yet deprecated in Chrome are duplicated elsewhere.
... I think getURL is the only thing left.

kmag: I think Chrome is moving to deprecate, but getURL is the big chunk that's left and hard to remove.

mikepie: For now I think we can leave it in, but we'll need to come back to it.

Florian: We can spec AND depreacate, if this isn't the way forward, but is still something UAs need for compat reasons.

kmag: We try not to support deprecated stuff.
... I don't think we need getBackgroundPage and the like. These are the kind of things we may come back to, but don't need in the first spec.

Florian: Do you want to go through the comments I've made in https://github.com/browserext/browserext/pull/4#issuecomment-245791954

mikepie: sure
... Comment 1 about titles: I started with something like what you suggested, but changed cause it felt long. Happy to change back.

Florian: Please do, would be easier to understand.

mikepie: Comment 2: I think this is normative, and I'll add details about what happens if you try disallowed things anyway.

kmag: We should define that as a CSP ruleset, rather than prose.

mikepie: I'll look at that.

Florian: Comment 3: you say two things cannot be set at the same time. What happens if you try?

kmag: That's browser specific, we support both at the same time.

mikepie: I think Chrome and Edge reject the manifest if you have both
... I'll make sure the language is clear

Florian: Since Chrome and Edge differ from Mozilla, does one side plan to align with the other?

kmag:We'd rather not change.

mikepie: I'll put some language around that.

Florian: Yes, please spec it one way, and add an issue about not all browsers doing it that way at the moment.

mikepie: Comment 4: CheckAnyPermissions is defined in MDN, what do we do about that?

kmag: Should be in the IDL spec eventually, link to MDN for now is fine.

Florian: Agreed. Put an inline issue to remind ourselves to have a normative source eventually.
... Comments 5 and 6 are about the IDL-explaining examples. I liked having one, wasn't sure why there was two.

mikepie: The second one got a value pulled from the manifest, and in the permissions, there's an array.

Florian: Can't we just keep the second example, and it covers everything?

mikepie: Can do that.
... I've heard that this kind of example wasn't necessary / w3c like, so I can remove.

Florian: There are different styles in writing specs. Some prefer to-the-point specs, with as little fluff as necessary, other prefer making them more readable and self explanatory to novices.
... Do as you prefer. I prefer having examples and explanations.

mikepie: I just noticed I messed up the section numbering. Will fix.
... In the IDL, I've used optional in several places, but I don't think that's permitted.

kmag: The IDL way to that is to add a question mark.

mikepie: Will do that

Status update on https://browserext.github.io/native-messaging/

kmag: I haven't been involved with the spec much. Hoped Andrew would be there, but he isn't. Happy to talk about the open issues.

Florian: Issue list: https://github.com/browserext/native-messaging/issues

kmag: I think all these issues belong together, and they seem to pertain mostly to web payments. It is not clear yet to me how they are related to what we're doing.

https://github.com/browserext/native-messaging/issues/1

Florian: It seems to me that what is proposed is a different API for a specific use case, not a generic solution. Maybe the specialized API is better for that use case, but I don't see how it addresses the generic concern.

mikepie: I think it is more a question about mobile.

RESOLUTION: Close issue 1 as wontfix, because this does not seem to address the generic solution, only a specialized use case.

https://github.com/browserext/native-messaging/issues/2

kmag: This is a proposal to allow native messagine to web pages, not just extensions.
... Doesn't seem related to extensions, and the security aspects seem underspecified.

RESOLUTION: Close as out of scope

https://github.com/browserext/native-messaging/issues/3

kmag: This is a follow up to number 2.
... Not relevant in the context of extensions.

mikepie: I agree. Issue 4 seems to be the same. I don't see how it relates to extensions.

RESOLUTION: and issue 4, out of scope for extensions. Redirect to the WebPlatform WG.

https://github.com/browserext/native-messaging/issues/5

kmag: Not sure this is needed as a special parameter. Such information can be communicated later.

mikepie: Doing it this way constrains the format, later it can be anything.

kmag: This may be about command line parameters.
... Doesn't seem necessary, you can do that with a message.

mikepie: Initialization can send any data it wants, in any format it wants, so this isn't necessary.

RESOLUTION: Close as wontfix, this can be achieved with existing communication mechanisms

Florian: kmag, when do you think aswan can have a draft for the messaging spec?

kmag: I'll check with him. Will let you know if we cannot have it before TPAC.

Florian: That's the end of the agenda. We're adjourned. See you at TPAC.

Summary of Resolutions

  1. Close issue 1 as wontfix, because this does not seem to address the generic solution, only a specialized use case.
  2. Close as out of scope
  3. close 3 and 4, out of scope for extensions. Redirect to the WebPlatform WG.
  4. Close as wontfix, this can be achieved with existing communication mechanisms