Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Publish minutes of 2022-08-04 meeting #253

Merged
merged 1 commit into from
Aug 14, 2022
Merged

Publish minutes of 2022-08-04 meeting #253

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
156 changes: 156 additions & 0 deletions _minutes/2022-08-04-wecg.md
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -0,0 +1,156 @@
# WECG Meetings 2022, Public Notes, Aug 4

* Chair: Timothy Hatcher
* Scribes: Rob Wu

Time: 8 AM PST = https://everytimezone.com/?t=62eb0c00,3c0
Call-in details: [WebExtensions CG, 4th August 2022](https://www.w3.org/events/meetings/d7bbce8f-549f-46ea-b440-ea6902f8707c/20220804T080000)
Zoom issues? Ping `@robwu` (Rob Wu) in [chat](https://github.com/w3c/webextensions/blob/main/CONTRIBUTING.md#joining-chat)


## Agenda: [github issues](https://github.com/w3c/webextensions/issues)

The meeting will start at 3 minutes after the hour.

* **Carry-over from previous meetings**
* None
* **Other new issues**
* [Issue 249](https://github.com/w3c/webextensions/issues/249): Proposal: add an option to make action.\* modifications persist across restarts
* [Issue 250](https://github.com/w3c/webextensions/issues/250): Current permission system and API design forces developers to create inefficient extensions
* [Issue 251](https://github.com/w3c/webextensions/issues/251): Should dNR dynamic rules reset on update?
* [Issue 252](https://github.com/w3c/webextensions/issues/252): Introducing browser.i18n.getOSLanguage
* **Open discussion queue (add yourself at the bottom)**
* None
* **Check-in on ongoing issues**
* [Issue 233](https://github.com/w3c/webextensions/issues/233), [244](https://github.com/w3c/webextensions/issues/244): Updating status labels
* [Issue 232](https://github.com/w3c/webextensions/issues/232): WECG at TPAC 2022
* [Issue 229](https://github.com/w3c/webextensions/issues/229): Extension Icon Design for Light/Dark/Custom Theme on Browser Toolbar
* [Issue 12](https://github.com/w3c/webextensions/issues/12): request: allow to retrieve a frameID from an <iframe> element
* [Issue 170](https://github.com/w3c/webextensions/issues/170): Proposal: Offscreen Documents for Manifest V3
* [Issue 162](https://github.com/w3c/webextensions/issues/162): DNR: disable individual static rules
* Concerns about [crbug 1271154](https://bugs.chromium.org/p/chromium/issues/detail?id=1271154) for mv3?


## Attendees (sign yourself in)

1. David Johnson (Apple)
2. Simeon Vincent (Google)
3. Rob Wu (Mozilla)
4. Oliver Dunk (1Password)
5. Timothy Hatcher (Apple)
6. Nick McGuire (1Password)
7. Tim Heflin (Keeper)
8. Carlos Jeurissen (Jeurissen Apps)
9. Gaurang Tandon (Blaze Today)
10. Benjamin Bruneau (1Password)
11. Craig Lurey (Keeper)
12. Steven McLintock (1Password)
13. Bradley Cushing (Dashlane)
14. Felipe Erias (Igalia)
15. Tyler Carson (Keeper)
16. Maxim Topciu (AdGuard)
17. Mukul Purohit (Microsoft)
18. Jack Works (Sujitech)
19. Brian Weinstein (Apple)
20. James Hycner (Keeper)


## Meeting notes

[Issue 249](https://github.com/w3c/webextensions/issues/249): Proposal: add an option to make action.\* modifications persist across restarts

* [timothy] Reporter is asking for a way to persist action modifications across restarts.
* [timothy] Initial thought is that these are frequently updated by the extension, and continuously persisting them might lead to a bad state that the developer forgot to clear.
* [simeon] Per-tab behavior may be challenging, or I guess the default behavior. Tab-specific settings cannot be persisted. Having non-tab-specific persist could make sense, but that would be inconsistent with the per-tab behavior.
* [simeon] Do other browsers persist state per tab?
* [timothy] Not in Safari.
* [rob] Not in Firefox, at least not via this extension API.
* [simeon] Would be nice, keep in mind for future iterations of the platform.
* [carlos] Seems the motivation for introducing this feature is to reduce code complexity and reduce background scripting. However, considering in mv2 and mv3 a developer still needs to provide this code as it can't know for sure this api is present. Thus it makes more sense to introduce this in mv4.
* [rob] A general solution to this is to provide an event near extension startup. This would allow the browser to notify the extension that there is no known desired state, and enable the extension to specify the desired state in response to it. This could apply to multiple APIs, e.g. scripting API, declarativeNetRequest, action API.
* [timothy] Had something similar for legacy Safari extensions; an invalidate event. Allowed an extension to update the state of toolbar items based on UI changes like switching tabs. The developer would need to use this event to have per-tab states — it was not automatic like it is with web extensions tab id approach. And with non-persistent background pages, it makes more sense to keep this as declarative as possible to reduce background wakes from an event.
* [timothy] Let's shelve this for now, and consider this for future improvements to the API.

[Issue 250](https://github.com/w3c/webextensions/issues/250): Current permission system and API design forces developers to create inefficient extensions

* [timothy] The issue covers multiple issues.
* [rob] E.g. tabs.onUpdated is very chatty. Firefox already [supports event filters](https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/WebExtensions/API/Tabs/onUpdated#additional_objects) for specific attributes and/or URLs. Something like that could make sense in other events too.
* [simeon] Nothing specific to mention; having a broad desire to support event filters on more event listeners. A challenge here is that the listener needs to be registered at the top level, and at that moment it may be unknown which filters need to be specified.
* [rob] The inability to register events dynamically is a broader issue. Supporting event filters would already help extensions that only need a static filter.
* [simeon] There's a general desire on the Chrome side to expand event filters to more event listeners. A notable challenge, though, is that there isn't a good way to update an event filter for an existing event listener registration.
* [timothy] Can we file an issue on the event filter update challenges? Hadn't considered this before now.
* [simeon] Will do.
* [oliver] This issue also expresses a desire for finer-grained permissions.
* [timothy] If you add finer-grained permissions, you would get a new prompt again.
* [timothy] FYI: Safari only prompts for host permissions today, not for any API permissions.
* [rob] FYI: Chrome has the concept of collapsing permission warnings when a permission warning is covered by another permission warning. Firefox doesn't do that at the moment, it prompts for every permission that has a warning.

[Issue 251](https://github.com/w3c/webextensions/issues/251): Should dNR dynamic rules reset on update?

* [timothy] Currently in Chrome, DNR rules are reset on update. This is surprising to me, and we haven't implemented that in Safari. What are everyone's thoughts on this? As written in the issue, I believe that dynamic rules are user-generated content, so it would be surprising if the rules were lost on updates. The argument from the Chrome side has been that these should be reset on updates because these may conflict with static rules on update.
* [simeon] I want to quickly expand on my mental model for Chrome's approach: statically declared rules (and content scripts from the scripting API) are registered on install/update. When extensions perform a dynamic registration, they indicate that outside of the static flow. The extension is then responsible for registering again. This is unfortunately not obvious.
* [rob] Any DNR API consumers with thoughts?
* [alexei] I just learned now that dynamic rules are reset. That is indeed surprising to me. This is indeed a tricky point, which needs to be explicitly communicated to developers. Are dynamically registered content scripts also reset?
* [simeon] Yes.
* [alexei] From the developer perspective, this needs to be consistent and clear between browsers.
* [timothy] I wasn't even aware of this when I implemented this in Safari, due to the lack of documentation.
* [rob] This also supports the need for an event where the browser indicates it has cleared state (referred to as “general solution” in the first topic of today's meeting).
* [timothy] Good point, there are potentially other reasons that would need the extension to re-register data. Should we make this issue cover both dNR and dynamic content scripts?
* [rob] scripting.registerContentScripts currently only supports path to extension resources, so that's currently not that big of a problem. However, if the API supports more (such as strings/code), then the deletion of dynamically registered data would be problematic.
* [mukul] Perhaps we should consider adding an option to the API that allows the extension to indicate whether it came from the user or the extension?

[Issue 252](https://github.com/w3c/webextensions/issues/252): Introducing browser.i18n.getOSLanguage

* [carlos] Browsers currently look at the OS language, and may use a simpler version of the language (without tag). Extensions could benefit from the more detailed version (e.g. nl-BE instead of just nl).
* [timothy] Yeah, I think that this makes sense. Sounds fine to me for Safari.
* [simeon] From my perspective, a Chrome issue would be welcome.

[Issue 233](https://github.com/w3c/webextensions/issues/233), [244](https://github.com/w3c/webextensions/issues/244): Updating status labels

* [simeon] Haven't looked at this since our last meeting. I believe Rob suggested consolidating discussion in a single issue, we should follow through on that.
* [carlos] Would be nice to do this sooner than later.
* [simeon] Timothy and Carlos indicated interest in helping here. My tentative plan is to create a doc to iterate on the plan, share it with interested parties for feedback, once we've got some consensus share the plan on the issue, and

[Issue 232](https://github.com/w3c/webextensions/issues/232): WECG at TPAC 2022

* [timothy] TPAC is a little over a month away. Recently got added to the TPAC registration page. Will need to get started planning what our 2-hour meeting will look like at the event. If anyone is attending, it would be good to know.
* [simeon] One of the shortlist items was “identifying topics”. As Rob called out in [a comment on the issue](https://github.com/w3c/webextensions/issues/232#issuecomment-1196975450), the Browser Testing and Tools WG have a meeting overlapping with out meeting (but they have one too on Friday). We may want to chat with the Service worker folks.
* [simeon] Any other groups that we should meet, or topics that we should discuss?
* [timothy] I think the app manifest format, see also next topic.
* [carlos] Note on TPAC: There are early bird tickets until tomorrow. If anyone is in Canada (Vancouver), consider participating.
* [simeon] I am tentatively planning to attend the whole week.
* [timothy] It is a hybrid conference, so remote participation is fully supported. I am planning to attend remotely.
* [rob] I'm planning to attend the whole week, together with a few team members.

[Issue 229](https://github.com/w3c/webextensions/issues/229): Extension Icon Design for Light/Dark/Custom Theme on Browser Toolbar

* [timothy] Carlos [commented](https://github.com/w3c/webextensions/issues/229#issuecomment-1205375586) about how the runtime API could look like.
* [carlos] My proposal is to have a behavior similar to setIcon. Some special considerations: In Firefox, `setIcon` currently overrides `theme_icons`. So it would make sense if it also overwrites setThemeIcons.
* [timothy] So essentially the last caller wins.
* [carlos] Exactly, aligns with Firefox's behavior. May want to revisit in a future manifest revision.

[Issue 12](https://github.com/w3c/webextensions/issues/12): request: allow to retrieve a frameID from an <iframe> element

* [timothy] Answer from Chrome? https://github.com/w3c/webextensions/issues/12#issuecomment-1193594916
* [simeon] Short version is: I've been doing some related work to gather documentation on documentIds, and how prerender and speculative loading relates to this. I'll try to get an answer to this soon.

[Issue 170](https://github.com/w3c/webextensions/issues/170): Proposal: Offscreen Documents for Manifest V3

* [timothy] Any update?
* [simeon] An initial implementation, a minimum viable prototype is on Chrome behind a flag. I'll comment on the issue to explain how one can do that. The capability exists, we're experimenting with this and we'll add some more features over time.
* [timothy] The proposal doc hasn't been updated since March, can you keep it updated as the design changes?
* [simeon] Proposals/design docs are weird in Chromium. They tend to be more of a launching off point than a canonical reference. I will look into updating the proposal this, but no guarantees. I've also been thinking about reference documentation for this feature, but given that the current implementation in Canary is behind a feature flag, we're in an odd liminal state between initial proposal and implemented feature.
* [timothy] If other browsers want to consider this, we need docs to see if and how we want to do this.

[Issue 162](https://github.com/w3c/webextensions/issues/162): DNR: disable individual static rules

* [timothy] A meeting or two I said that I would talk with the team; basically we would have to recompile all rules if anything changes in Safari. We basically compile everything in one big state machine. If we want to support this, we don't want this to be called frequently. That being said, we don't rate-limit dynamic or session rule changes today either.
* [felipe] On the API proposal document, I got a lot of feedback from a Chrome engineer. First thing that I wanted to mention is to point to the document and the conversation. At the moment the API relies on filter lists. Extension developer needs to remember which rule/filter list is enabled when rulesets are toggled. Finally, an idea we've been talking about, is the idea of a mutable flatbuffer file. The flatbuffer format is efficient, an idea that is floating around is an extra field that indicates whether the rule is enabled or not.
* [timothy] Going back to the dynamic rules reset on update (discussed earlier); do we have similar concerns here?
* [felipe] Rule IDs are just numbers, on updates the rules could be completely different so it is reset on update.

Concerns about [crbug 1271154](https://bugs.chromium.org/p/chromium/issues/detail?id=1271154) for mv3?

* [simeon] I recently spoke with the engineer on a similar/related issue that was easier to reproduce. We're actively investigating, but the difficulty is that we don't have a reliable test case to reproduce the problem. If anyone is interested in this issue and has additional information on the characteristics that cause it, or metadata such as browser version/OS version, any information to help investigating this would be helpful.

The next meeting will be on [Thursday, August 18th, 8 AM PST (3 PM UTC)](https://everytimezone.com/?t=62fd8100,3c0).
5 changes: 3 additions & 2 deletions _minutes/README.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -10,23 +10,24 @@ After the end of each meeting, meeting notes are published here.

## Upcoming meetings

- 2022-08-04 at 8 AM PST = https://everytimezone.com/?t=62eb0c00,3c0
- 2022-08-18 at 8 AM PST = https://everytimezone.com/?t=62fd8100,3c0
- 2022-09-01 at 8 AM PST = https://everytimezone.com/?t=630ff600,3c0

## Past meetings

* 2022-08-04 ([minutes](2022-08-04-wecg.md))
* 2022-07-21 ([minutes](2022-07-21-wecg.md))
* 2022-07-07 ([minutes](2022-07-07-wecg.md))
* 2022-06-23 ([minutes](2022-06-23-wecg.md))
* 2022-06-09 ([minutes](2022-06-09-wecg.md))
* 2022-05-26 ([minutes](2022-05-26-wecg.md))
* 2022-05-12 ([minutes](2022-05-12-wecg.md))

<details>
<summary><strong>All past meeting notes</strong></summary>

**2022**

* 2022-08-04 ([minutes](2022-08-04-wecg.md))
* 2022-07-21 ([minutes](2022-07-21-wecg.md))
* 2022-07-07 ([minutes](2022-07-07-wecg.md))
* 2022-06-23 ([minutes](2022-06-23-wecg.md))
Expand Down