Skip to content

Latest commit

 

History

History
135 lines (107 loc) · 11.3 KB

2021-08-19-wecg.md

File metadata and controls

135 lines (107 loc) · 11.3 KB
Raw

WECG Meetings 2021, Public Notes, Aug 19

  • Chair: Simeon Vincent
  • Scribes: Mukul Purohit

Time: 11 PM PDT = https://everytimezone.com/?t=611d9f00,708

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

Zoom issues? ping @robwu (Rob Wu, Mozilla) in chat

Agenda: github issues

  • PR 59: Add sidebar_action to manifest keys
  • Issue 60, PR 61: Add the name and short_name prose

Queue (add yourself at the bottom)

  • Meeting schedule
  • Issue 1: What to do with the older CG?
  • Krzysztof Modras: is discussion on webextension features in the scope of interest of this WG? For example performance implication of manifest v3 model
  • Issue 30: Adding some form of deploy on PR to see the result

Attendees (sign yourself in)

  1. Daniel Glazman (Dashlane)
  2. Rob Wu (Mozilla)
  3. Oliver Dunk (1Password)
  4. Richard Worth (Capital One)
  5. Denis Schneider (Dashlane)
  6. Mélanie Chauvel (Dashlane)
  7. Mukul Purohit (Microsoft)
  8. Simeon Vincent (Google)
  9. Jesse Trana
  10. Andrew Beyer (1Password)
  11. Krzysztof Modras (Ghostery)
  12. Philipp Kewisch (Mozilla)

Meeting notes

PR 59: Add sidebar_action to manifest keys

  • [Mélanie] Summary : sidebar action PR introduces a new key to the manifest
  • [Simeon] PR merged, thanks for adding this

Issue 60, PR 61: Add the name and short_name prose

  • [Simeon] Submitted by Timothy, this PR adds more meaningful descriptions to these properties. Also raises a couple questions.
  • [Simeon] Chrome and Firefox take strings of arbitrary length, but both browsers' extension stores restrict the name to 45 chars. Should we capture that in the spec? Inclined to capture that as ecosystem is more than the browser (i.e. distribution channel)
  • [Mélanie] Maybe good idea to address the limitation
  • [Daniel] The spec does not include restriction but web-stores could restrict the length. This can be indicated in the document
  • [Rob] If anything, we could specify the minimum supported length across vendors.
  • [Daniel] If restriction is specified then browsers would need to enforce it.
  • [Rob] Are you referring to short_name only?
  • [Simeon] No, name, shortname, icons, or any other property that has limitations imposed by parts of the ecosystem beyond the browser itself.
  • [Simeon] The text that Timothy provided is a big improvement over the current placeholder text, but it does raise questions about the scope of what we're specifying. We can use another discussion thread. We should have more folks for consensus
  • [Simeon] In the same PR, the concept of localization is introduced, we should capture that in another issue. Will file a new issue about this topic. Contributions welcome; otherwise I will eventually submit PR.

Issue 53: Decompose manifest.json spec work into action items members can PR

  • [Simeon] There are now few entries in the document for manifest keys. Issue 53 proposes that we decompose manifest json into actual actionable work. We can create the issues for each item or just do PRs.
  • [Daniel] Simpler the better. PRs only is fine
  • [Rob] We can add issues if identified else PRs are good
  • [Simeon] Consensus is to tackle individual properties as PRs. If you're interested in helping, feel free to open a new PR.

Administrativia

  • [Rob] What is the process to select issues for this meeting?
  • [Simeon] Selecting the Agenda items that support the goal identified in the charter: specify a common core. Thought process was to focus on pursuing the common core in agenda items, then open discussion to topics of interest via the queue. Open to improving the process.
  • [Mélanie] Can we add agenda items?
  • [Rob] Ping me for items on the Matrix chat. This time we have plenty of time to discuss any other topic.
  • [Simeon] For the most part the doc is open, but it is locked temporarily before publishing
  • [Daniel] Could we improve the manifest spec and define the types of property
  • [Rob] We touched upon this Web IDL vs JSON in one of the previous meetings.
  • [Daniel] Manifest is JSON, can we define the types of the values. How are we going to define the types e.g. CSS property
  • [Simeon] Inclination to follow the format used by App Manifest. Will add the examples to matrix.
  • [Mélanie] Research for specs that could be used as inspirations to define the manifest json document. Inclined to do research across multiple resources.
  • [Simeon] Can you provide some examples
  • [Mélanie] Browser extension community group spec
  • [Simeon] I recall that it Lists all the properties as table
  • [Simeon] WebApp manifest spec vs Browser Extension community spec are using different ways. WebApp manifest feels like JS specification whereas the other one is simple and specifies as an array of objects. I am hesitant to pick one. We could consider re-using the definition by linking to the other spec. Would prefer to not re-write the internals of algorithms that are already specified elsewhere
  • [Daniel] Web App manifest is a working draft. We should not add links to resources that can go away.
  • [Simeon] Makes sense. We should only reference published specifications from other groups.
  • [Daniel] Agree to work on general things first.
  • [Philipp] What are the next set of things we should work on?
  • [Simeon] Follows naturally from work on manifest; Localization is an example. Do suggest if you have one.
  • [Philipp] I was thinking about security and that leads towards content-script.
  • [Simeon] Agree that CS seems like a good area to begin exploring. Volunteers welcome :)

Future meetings in this time slot

  • [Rob] At the end of last week’s meeting we already mentioned the possibility of reducing the frequency of meetings in this time slot, since the other time slot has more participation. Any objections against doing so?
  • [Simeon] Hesitant as this approach is more inclusive. But there is a practical benefit to having single time, so I reluctantly support consolidating on a single time slot.
  • [Mélanie] I recall we discussed changing the cadence a few meetings ago.
  • [Mukul] We discussed to change cadence of this slot only
  • [Simeon] I do remember discussing changing the cadence of the meeting at this time. Probably best to discuss in an issue.
  • [Rob] Outside of this time we can use github-issue to discuss. Should we open an issue?
  • [Daniel] Chairs can call for consensus and make a decision
  • [Simeon] Agreed. We should discuss in an issue and put it to a vote next meeting

Issue 1: What to do with the older CG?

  • [Simeon] Florian was not able to attend this call. We wanted to discuss the future of the resources in older CG. Maybe we can take the next step and drive to a conclusion. As an example, raise and submit the PR in the previous CG.
  • [Daniel] Prev CG is officially extinct so creating a PR is not valid.
  • [Simeon] Can we just have a PR in older CG that calls out the state of the CG i.e. it is retired and update the readme to call out the same. Followup with W3C staff to officially mark the group as inactive; update the blog to redirect to CG.
  • [Mélanie] Should we create a new issue or use this issue number 1.
  • [Simeon] We can use issue 1 unless the text is unclear.
  • [Rob] Can we get Florian over any other channel and conclude the same.
  • [Simeon] I will follow up with Florian on issue 1.

Features that are in scope in this CG

  • [Krzysztof Modras] Is discussion on WebExtension features in the scope of interest of this WG? For example performance implication of Manifest V3 model
  • [Krzysztof] Working for Ghostery. Want to discuss the perf implication of DNR and Service workers. Is this discussion in scope?
  • [Rob] Yes, in the scope. Are you specifically referring to Service Workers?
  • [Krzysztof] With Service Workers we need to instantiate state & objects on-demand. My first Q is that should we discuss in this meeting or should use another channel or issue
  • [Rob] This topic has been raised before at #51 and open issues with "topic:service worker" label
  • [Simeon] Agree that this is in the scope. We are talking about the future of the Browser Extension Model. As part of the group we are trying to capture the common parts so that the developers can target their work for multiple browsers. Feel free to discuss service-worker limitations and challenges in this group. I agree there are issues with SW and the Chrome team is interested in the use-cases and points of failures. There has been a lot of MV3 feedback, but much of it is lot of feedback and it would be useful to get feedback around service-worker model is not working currently, and we are trying to get to a solution that can work for browsers and developers
  • [Krzysztof] Happy to hear that. There are some issues with our current implementation interacting with service-workers.
  • [Daniel] I believe that the Side effects are well known to all and including the google team. The 5 minute limit is harsh. I am surprised by your reaction.
  • [Simeon] The 5 minute cutoff is a sharp edge and the Chrome team wants to make it less dangerous. Probably not surprising that this has been a repeated topic of discussion. Interested in exploring ways to provide more reliable behavior v/s providing persistence. As an example one of suggestion is to provide a way for extensions to request service worker unload when it can be safely terminated
  • [Daniel] Extension authors are trying multiple ways to increase (or workaround) the time limit as it is expensive to reload the state. Not everything can be stored in public storage as it may be security / privacy specific. Think of user impact - _seconds _of wait.
  • [Simeon] Has heard some of them, in certain cases caused by front loading more work than necessary in an event-based model. In some cases re-architecture of the extension is necessary. Current implementations have been optimized with long-lived threads available.
  • [Daniel] Optimized is not the correct term; have used what was available. WebExtension vendors used persistence of the background and in-memory storage because that’s what was available in v2 model.
  • [Rob] Suggest to break this discussion in the interest of time.

Issue 30: Adding some form of deploy on PR to see the result

  • [Mélanie] Would be nice to get a preview.
  • [Rob] We discussed this earlier to create the functionality to submit the PR - #30
  • [Mukul] I would try to get the github actions work this week

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