Skip to content

Latest commit

 

History

History
153 lines (128 loc) · 11.7 KB

2021-08-05-wecg.md

File metadata and controls

153 lines (128 loc) · 11.7 KB
Raw

WECG Meetings 2021, Public Notes, Aug 5

  • Chair: Timothy Hatcher
  • Scribes: Rob Wu

Time: 8 AM PDT = https://everytimezone.com/?t=610b2a00,384

Call-in details: https://lists.w3.org/Archives/Member/internal-webextensions/2021Jun/0000.html

Zoom issues? ping @zombie (Tomislav Jovanovic, Mozilla) in chat

Agenda: github issues

  • Issue 50: Document "browser_action" and "page_action" or document "action"…
  • Issue 21: How should sidebarAction be considered, since it’s only implemented in two browsers?
  • Issue 13: Where do we start for a draft?
    • Specifically "Should we contribute WebIDL files for the APIs?"
  • Issue 43: Proposal for Manifest v3: Have less restrictive security measures for force-installed extensions
  • Issue 45: Participating in TPAC 2021

Queue (add yourself at the bottom)

  • hard to find Zoom link

Attendees (sign yourself in)

Put a *** if you prefer this time slot:

  1. Tomislav Jovanovic (Mozilla) ***
  2. Daniel Glazman (Dashlane) ***
  3. Oliver Dunk (1Password)
  4. Philipp Kewisch (Mozilla) ***
  5. Rob Wu (Mozilla) ***
  6. Timothy Hatcher (Apple) ***
  7. Peter Saint-Andre (Mozilla) ***
  8. Bradley Cushing (Dashlane) ***
  9. Thierry Régagnon (Dashlane) ***
  10. Sam Macbeth (DuckDuckGo)
  11. Jon Howard (Easyfundraising) ***
  12. Ellie Epskamp-Hunt (Apple)
  13. Nir Nahum (WalkMe)
  14. Mélanie Chauvel (Dashlane)
  15. Marwan Liani (Dashlane)
  16. Shane Caraveo (Mozilla)
  17. Todd Schiller (PixieBrix) ***
  18. Pawel Wszola (OceanHero)
  19. Simeon Vincent (Google) ***
  20. Mukul Purohit (Microsoft)
  21. Sohail Rajdev (Microsoft)
  22. Andrew Beyer (1Password) ***
  23. Don Hopkins (Ground Up Software) ***
  24. Jack Works (Sujitech)
  25. Richard Worth (Capital One)

Meeting notes

Issue 50: Document "browser_action" and "page_action" or document "action"…

  • [timothy] During Mélanie’s first contribution to the manifest format the question of what to do with browser_action/page_action/action came up.
  • [simeon] Specify overlap between MV2 and MV3
  • [tomislav] Specify common where there are at least 2 implementations
  • [glazou] we’re not forced to have 2 compatible implems per feature; we’re supposed to describe the WebExtensions state-of-the-art and we don’t have to be conformant to REC exit criteria and our specs go to WG for that
  • [simeon] Example of Firefox’s contentScripts API vs Chrome’s scripting API; similar functionality, different approaches to registering content scripts dynamically.
    • [rob] Firefox will deprecate the contentScrips namespace in favor of the scripting namespace; we can collaborate in this group to design a cross-browser compatible API.
    • [simeon] In the future, it might be nice if we could get to the point where browsers support multiple versions of APIs so that we don't depend on the whole ecosystem agreeing on one canonical version at a time.

Issue 21: How should sidebarAction be considered, since it’s only implemented in two browsers?

  • [timothy] Opera and Firefox have implementations, are two enough to spec the API?
  • [simeon] No objections to speccing it, except it is not in the overlap of MV2+MV3.
  • [Mélanie/Timothy] sidebarAction is not being actively removed in mv3, therefore it is a continuation.
  • [glazou] Consider showing the result of individual implementations for the browser. Add this to the templates for each entry in the manifest. This should help a lot for the future.
    • For example as shown at wpt.fyi
    • [simeon] Positive towards a common set of tests
    • [philipp] There is also an effort in the browser-compat-data project that is used to e.g. render compatibility tables on MDN.
    • Result: glazou will file an issue to track this further.
  • [Simeon] We don’t need to conform to other specs, if we wanted to add visual indicators we should.
  • Consensus: We should proceed by specifying it, there are 2 implementations (despite it not being a part of MV3 right now).
  • Mélanie will look into documenting the manifest property, the issue will remain open for additional work.

Issue 13: Where do we start for a draft?

  • [from issue] "Should we contribute WebIDL files for the APIs?"
  • [simeon] Sounds like a good idea. Talked to a related team, integrating definitions into spec for scripting. There is a split in how well that works. Complex or optional values are difficult to write in webidl, especially in a deeply nested part of the manifest. Team was looking to extend webidl, infrastructure folks were not very fond of that idea.
  • [timothy] webidl would be more for the javascript side of things. Using JSON Schema for the manifest.
  • [simeon] How are browsers doing this? Parsing the html file and plug that into their systems?
  • [tomislav] Use webidl as the basis, it will be adjusted when used in the browsers. The files won’t be used wholesale.
  • [timothy] Same for webkit. Apple adds attributes and annotations. More of a copy/modify scenario.
  • [don] (referencing Simeon’s earlier comment) Is this similar to how typescript defines the structure?
    • [simeon] Yes, there are likely similar capabilities in webidl
  • [tomislav] In Firefox we are currently not using webidl, but JSON schemas as originally used in Chromium. Webidl is less descriptive, we would lose some specifity that we would still need to implement. If we go with webidl in the spec, we wouldn’t be able to cover all of the cases. We’re transitioning to webidl for ServiceWorkers, but we need JSON Schema for other validations.
  • [timothy] Maybe a combination of both. Use webidl for the API level, for the individual dictionaries (e.g. tab query) we specify a separate json schema.
  • [philipp] do we need both?
  • [Mélanie] Webidl would be distributed with the spec?
    • [simeon] This is what the webapp CG does, they publish separate schema files to jsons-schemas.org
    • [Mélanie] JSON Schema helpful when using external tools, e.g. mocking all API methods.
    • [timothy] If we can specify everything in json schema that would be great, we could generate
      • [simeon] We can’t; JSON schemas does not support return types.
      • [todd] json schema is only the data, everything further would be swagger or (opensomething?).
    • [don] Can we translate the other way (webidl -> json schema)
    • [timothy] webidl can be translated into anything, using a tool. Could generate a json schema shell.
    • [simeon] Chrome generates extension docs from IDLs and JSON schemas
  • [timothy] Moving discussion to the issue seems like the next logical step.
  • [simeon] What is the goal of having webidl or json schema?
    • [simeon] Spec contained idl, this was consumed in the browsers, that doesn’t seem to be the case.
    • [timothy] There is a process to import these files, Apple adds more attributes.
    • [tomislav] Easier to copy something from the spec and adapt as needed
    • [rob] what type of info is in the apple webidl files? Is it a fundamentally lacking feature in WebIDL?
    • [timothy] very specific stuff, e.g. was it implemented as NSObject. Webidl has its limits here.
    • [timothy] If we separate the object definitions as Mélanie mentioned, this would be good for tooling. Unclear if we can specify everything.
    • [Mukul] How does WebIdl handle variations in APIs and types by browser implementations?
    • [timothy] It gets complicated when options are re-arranged, problems can come up if there is a lot of churn. Mv2 and mv3 are mostly compatible to each other, this is easily done in webidl by new scripting namespaces.
    • [don] Does webidl have a generic annotation mechanism to decide when to use what?
    • [timothy] There are generic attributes that could be used.
    • [don] We could make that up, or use something someone has done
  • [Oliver] Original intention, browser vendors are most implemented in putting together the draft. How can we distribute the workload, 1Password is very interested in contributing as well.
    • [timothy] All for community contributions. See how we can split this up
      • Digging into the sub-levels of the manifest
    • [oliver] Sounds like spec is the main focus, how can we allocate this?
    • [timothy] In previous meetings we agreed that the manifest was a good starting point.
    • [glazou] To contribute, make a proposal to get it accepted by the group. It had to be kickstarted for others to contribute, so we can start contributing. Editors (and in part Chairs) will be able to help getting PRs reviewed and accepted.

Issue 43: Proposal for Manifest v3: Have less restrictive security measures for force-installed extensions

  • [timothy] In the issue the OP asks for relaxed restrictions for enterprise-installed extensions.
  • [simeon] Do other browsers have the concept of force installation/side loading. What does Firefox do?
  • [tomislav] We have something for linux distros and enterprise. This doesn’t seem like an issue that is in scope for this group.
  • [nir] As an extension developer, we are counting on having the same API on all the browsers. If any browser would choose their own way to tackle this. Would be great to have a single codebase. If it is detected that the extension was not installed from the store but from central IT, in that case certain APIs would still be enabled. Example: blocking webRequest.
    • [tomislav] Counter-example, we don’t distinguish between enterprise or not. We have blocking webRequest in both mv2 and mv3.
    • [glazou] This is explicitly out of scope in the charter. Quote: Deployment mechanisms. We should not be discussing this.
    • [nir] Not talking about the deployment, more about the APIs.
    • [timothy] We could only describe the APIs, it would be up to the browser vendors to decide how to expose them.
    • [rob] What is the goal behind filing the issue?
    • [nir] Deprecations in mv3 are affecting vendors and customers. Enterprise use cases are affected, if we can accommodate this in the group everyone would win. Enterprises have higher requirements, browser vendors want enterprises to use the browsers. Restrictions make sense for end-users, this makes less sense for enterprise where there is a security team.
    • [rob] So you’re asking for the spec to describe privileged APIs that are disabled/enabled in certain cases, is that what you (Nir) are asking?
      • [Nir] Yes
    • [philipp] We talked about browser compat data, can we just make this a special case of that (e.g. supported: no, caveat it is supported in the enterprise case)
    • [simeon] In the context of this group we could consider making it easier to feature-detect APIs
      • [timothy] De facto standard is to check whether the API is present.
      • [tomislav] Thumbs up

Issue 45: Participating in TPAC 2021

  • [simeon] Please add ideas to this issue to help us organize outreach for TPAC
  • No time left, deferred to the next meeting.

(queue) hard to find Zoom link

The next meeting will be on Thursday, August 19th, 11 PM PDT (Friday, August 20th, 6 AM UTC). After that meeting we will evaluate whether we need to adjust the current cadence.