Skip to content

Latest commit

 

History

History
111 lines (81 loc) · 6.84 KB

2021-09-02-wecg.md

File metadata and controls

111 lines (81 loc) · 6.84 KB
Raw

WECG Meetings 2021, Public Notes, Sep 2

  • Chair: Timothy Hatcher
  • Scribes: Rob Wu

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

Call-in details: https://www.w3.org/events/meetings/7fc25ca5-a50c-498c-82e5-f48fc96e1637/20210805T150000

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

Agenda: github issues

  • Issue 63: Adjust frequency of 11 PM PDT / 6 AM UTC meeting
  • Issue 45: Participating in TPAC 2021
  • Issue 64: Specify the hierarchy of files
  • Issue 67: Streamline homepage_url, author and developer keys
  • Issue 14: manifest error handling for unknown properties

Queue (add yourself at the bottom)

  • Is the extension security model in scope for the spec? (Jonathan Kingston)

Attendees (sign yourself in)

  1. Oliver Dunk (1Password)
  2. Rob Wu (Mozilla)
  3. Simeon Vincent (Google)
  4. Andrew Steel (LastPass)
  5. Tomislav Jovanovic (Mozilla)
  6. Jon Howard (easyfundraising)
  7. Daniel Glazman (Dashlane)
  8. Jack Works (Sujitech)
  9. Mélanie Chauvel (Dashlane)
  10. Thierry Régagnon (Dashlane)
  11. Bradley Cushing (Dashlane)
  12. Marwan Liani (Dashlane)
  13. Mukul Purohit (Microsoft)
  14. Timothy Hatcher (Apple)
  15. Brendan Riordan-Butterworth (eyeo GmbH)
  16. Alan Foster (easyfundraising)
  17. Jonathan Kingston (DuckDuckGo)
  18. Jesse Trana
  19. Ellie Epskamp-Hunt (Apple)

Meeting notes

Issue 63: Adjust frequency of 11 PM PDT / 6 AM UTC meeting

  • [timothy] Let’s use 8 AM PDT / 3 PM UTC by default, unless a different time zone is needed.
  • [simeon] Heard before that people prefer consistent meeting times even if the time is not ideal for them.
  • [tomislav] One of the reasons to introduce the alternative meeting time is to allow Florian to join, but so far he hasn’t been able to make it. We can schedule a separate meeting if needed.
  • [timothy] will update the W3C calendar
  • [rob] I will edit the README and minute templates.

Issue 45: Participating in TPAC 2021

  • [timothy] Received reminder to join TPAC.
  • [tomislav] Heard that WebDriver BiDi is interested in isolated worlds

Issue 64: Specify the hierarchy of files

  • [timothy] It would be good to describe the top-level files such as manifest.json and _locales in the spec. Contributions are welcome.
  • [oliver] Willing to work on this issue.

Issue 67: Streamline homepage_url, author and developer keys

  • [simeon] Would be useful to start with describing the properties, which enables us to get into the specifics of resolving specific values when there are multiple locations for the same info.

Bikeshed PR automation

  • [simeon] In #61 syntax errors appeared, I recalled that someone was going to work on automation to preview PRs.
  • [mukul] planned to do that but didn’t have time for it. Will try to do this before the next meeting as part of #30.

Issue 14: manifest error handling for unknown properties

  • [timothy] what to do with unknown properties. Know that Chrome is somewhat strict and Safari/Firefox more flexible. Given the cross-browser nature we should document the desired behavior of unknown properties, ideally to not treat them as severe errors.
  • [tomislav] The common behavior is that implementations throw when known keys have invalid types.
  • [glazou] don’t forget original context ; extension vendors don’t want to have to generate multiple manifests on a per-browser basis. Ideally unsupported properties should be ignored so that one manifest can be used in multiple browsers.
  • [timothy] Safari generalizes chrome_ to browser_ (e.g. supporting browser_settings_overrides in addition to chrome_settings_overrides). I would imagine Chrome to be throwing if it detected browser_settings_overrides.
  • #14 (comment)
    • [rob] Someone asks for support to have the ability to override top-level properties in a subkey (e.g. browser_specific_settings).
    • [glazou] Would ideally not see a new reality where browsers fake their browsers to accommodate extensions.
    • [rob] At some point in the past I wanted the ability to override manifest keys for specific browser versions to avoid errors in browsers that did not recognize the new value. This benefit does not weigh against the complexity of enforcing and validating the manifest though, e.g. validators unaware of this override could inadvertently be bypassed.
    • [timothy] Safari’s only critical errors are if JSON is incorrect or the manifest version is invalid.
    • [simeon] will file crbug

Manifest content, follow-up to previous week (issue 60).

  • [simeon] Should the manifest account for things like maximum name length imposed by web stores?
  • [glazou] Put constraints in an informal note if it’s not strictly part of the spec.
  • [simeon] We could put the maximum length in the JSON schema, so that external tooling can validate the schemas.
  • [timothy] Against constraints since different platforms may have different needs for the length, e.g. on mobile there may be even less space.
  • [simeon] Chrome doesn’t enforce limitations on short_name, the Chrome Web Store does.
  • [tomislav] While I’m in favor of adding informal notes, note that store policies are explicitly outside the scope of this group.
  • [simeon] Consensus is to add a non-normative note.
  • [timothy] It is a good idea to call out potential issues in the spec, even if informally.

Is the extension security model in scope for the spec? (Jonathan Kingston)

  • [jkt] Is it possible to describe the security model in the spec, for example the practice where browsers maintain a set of restricted URLs that are shielded from extensions.
  • [rob] Please file a new issue in the repo so that we can discuss this in more detail at the next meeting.
  • jkt opened issue 71 after the meeting.

Follow-up to previous meeting, “Features that are in scope in this CG”

  • [jesse] Revisit Simeon’s suggestion for ServiceWorker use cases
  • [simeon] Will file an issue to track this.
  • simeon opened issue 72 after the meeting.

The next meeting will be on Thursday, September 16th, 8 AM PDT (3 PM UTC).