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

Jump to bottom

Publish minutes of 2023-02-16 meeting #354

Merged
merged 1 commit into from
Feb 17, 2023
Merged

Publish minutes of 2023-02-16 meeting #354

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
159 changes: 159 additions & 0 deletions _minutes/2023-02-16-wecg.md
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -0,0 +1,159 @@
# WECG Meetings 2023, Public Notes, Feb 16

* Chair: Timothy Hatcher
* Scribes: Rob Wu, Tomislav Jovanovic

Time: 8 AM PST = https://everytimezone.com/?t=63ed7200,3c0
Call-in details: [WebExtensions CG, 16th February 2022](https://www.w3.org/events/meetings/731a34ef-46f2-4ac6-8ae0-b30998883a29/20230216T080000)
Zoom issues? Ping @zombie (Tomislav Jovanovic) 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.

* **Check in on PRs**
* [PR 331](https://github.com/w3c/webextensions/pull/331): Add User Scripts API proposal
* **Other new issues**
* [Issue 350](https://github.com/w3c/webextensions/issues/350): Discuss limits applied to storage.session API
* [Issue 351](https://github.com/w3c/webextensions/issues/351): Discuss limits applied to storage.local and storage.sync API
* [Issue 352](https://github.com/w3c/webextensions/issues/352): SQLite via OPFS for Chrome Extension isn't quite supported
* [Issue 353](https://github.com/w3c/webextensions/issues/353): Proposal: support onEnabled event when the extension from disabled state to enabled state
* **Open discussion queue (add yourself at the bottom)**
* \[Oliver\] [Issue 346](https://github.com/w3c/webextensions/issues/346): New API: UserSettings.isOnToolbar change event
* **Check-in on ongoing issues**
* [Issue 344](https://github.com/w3c/webextensions/issues/344): Regular expressions in DNR API (regexFilter)
* [Issue 229](https://github.com/w3c/webextensions/issues/229): Extension Icon Design for Light/Dark/Custom Theme on Browser Toolbar
* [Issue 269](https://github.com/w3c/webextensions/issues/269): declarativeNetRequest API: have isUrlFilterCaseSensitive condition set to false by default


## Attendees (sign yourself in)

1. Rob Wu (Mozilla)
2. Oliver Dunk (Google)
3. Richard Worth (Capital One)
4. Dmitriy Seregin (AdGuard)
5. Giorgio Maone (NoScript, Tor)
6. Benjamin Bruneau (1Password)
7. Frederic Rivain (Dashlane)
8. Tomislav Jovanovic (Mozilla)
9. Timothy Hatcher (Apple)
10. Luke Selker (Dashlane)
11. Maxim Topciu (AdGuard)
12. Steven McLintock (1Password)
13. Sam Macbeth (DuckDuckGo)
14. Tyler Carson (Keeper)
15. Tim Heflin (Keeper)
16. David Johnson (Apple)
17. Mukul Purohit (Microsoft)
18. Kiara Rose (Apple)
19. Simeon Vincent


## Meeting notes

[PR 331](https://github.com/w3c/webextensions/pull/331): Add User Scripts API proposal

* [rob] Looks good to merge, no outstanding issues, let's merge it.
* [tiimothy] Agree.
* [oliver] Other than the namespace discussion, looks like everyone agrees.
* [rob] I mildly prefer a new namespace, but Devlin felt strongly about re-using the runtime namespace. We can start with what we have now, and if really necessary change it later.
* [timothy] I'd be fine with exposing it at runtime. I went and approved it, you can merge it Rob.
* [rob] Will do after the meeting.

[Issue 350](https://github.com/w3c/webextensions/issues/350): Discuss limits applied to storage.session API

* [timothy] Chrome is the only shipping, Safari has implementation in Tech Preview, and we matched initial limits of 1 MB, but recently bumped to 10 MB, we heard from password managers the need to store encryption keys and similar.
* [rob] We'll be starting with 10 MB, but should nail down what exactly 10 MB means, is that the length of input or serialized storage or what?
* [timothy] While Chrome counts the in-memory structures, Safari counts the size of the JSON-serialization of the data.
* [rob] Would we consider another serialization mechanism? JSON is not very efficient, and does not support typed arrays for examples.
* [timothy] I'd be supportive of structured cloning.
* [tomislav] We use structured cloning instead of JSON in some APIs (extension messaging).
* [timothy] Are there cases where structured cloning fails where JSON works?
* [tomislav] An object with functions for example.
* [frederic] The password manager use case also includes storing some additional data as an optimization.
* [rob] And even if the memory storage quota is insufficient, you could encrypt the data and store parts with other storage APIs.
* [frederic] Yeah, we always need to have a division between “hot” and “cold” data.

[Issue 351](https://github.com/w3c/webextensions/issues/351): Discuss limits applied to storage.local and storage.sync API

* [timothy] Current limits: `storage.local` is 5 MB, `storage.sync` is 100 KB. We see a number of extensions requesting unlimitedStorage because they need a little more than 5 MB. If we're considering to bump the session storage to 10 MB, then we may as well adjust the limit here accordingly.
* [oliver] The implementation of storage in Chrome is not ideal. It seems if people are requesting unlimited storage when they need just a bit more, we should find some middle ground.
* [rob] Seems reasonable, in practice developers will just ask for unlimited storage, so let's consider bumping the limit once we settle on the quota for storage.session.
* [timothy] I don't see a reason to bump sync storage. We don't support storage.sync in Safari, but that limit should be constrained.
* [rob] Agreed.

[Issue 352](https://github.com/w3c/webextensions/issues/352): SQLite via OPFS for Chrome Extension isn't quite supported

* [timothy] Not much to say, looks like a wasm-based SQLite implementation using OPFS, and it is not working in Chrome.
* [oliver] Origin-private filesystem API is used for the new SQLite implementation. Most of the OPFS API is available to service workers, but the createSyncAccess handle API is currently only available to workers, but not available to service workers. Are extension SW different enough to support it?
* [tomislav] Do we have any background on why it's available to workers but not service workers? Mozilla is currently implementing OPFS, but don't know the progress offhand.
* [rob] We should consult the owners of OPFS and workers/service workers.
* [timothy] Historically we aren't considering exposing features to extensions that aren't ready for the web yet.
* [timothy] Safari does not support OPFS yet.
* [rob] Firefox does not support service worker based extensions yet, and Safari does not support OPFS. So this bug is currently mainly of interest in Chrome.
* [oliver] I'll ask internally (follow-up: chrome).

[Issue 353](https://github.com/w3c/webextensions/issues/353): Proposal: support onEnabled event when the extension from disabled state to enabled state

* [timothy] Current onStartup/onInstalled events seem not enough to understand when you're being woken up just from an event or from being disabled/enabled. I'd be supportive of this feature in Safari.
* [rob] runtime.onInstalled would be a good fit for this feature.
* [timothy] Not inclined to extend onInstalled because not feature detectable?
* [rob] It is feature-detectable because of the existing enum is available on the namespace (runtime.OnInstalledReason.something). Extensions should already be prepared to deal with events other than the extension installed (e.g. browser install), so firing the event more often will probably not cause issues.
* [oliver] runtime.onInstalled is not fired in unpacked extensions in Chrome. How is that in other browsers?
* [tomislav] We do in Firefox.
* [timothy] If we find that most extensions are fine and are already checking the event, we can probably do this.
* [alexei] FYI, the browser differences between these APIs are significant enough and there are enough browser-specific corner cases/gotchas/bugs that as an extension developer, I would much rather use extension storage to reimplement oninstall/onupdate logic I require for myself.
* [rob] Had a similar solution for similar reasons (working as an extension developer, not browser engineer).
* [timothy] Looks like we could improve this area to help everyone.
* [rob] So Safari is supportive, we (Firefox) are supportive too. What about Chrome?
* [oliver] Let's add “follow-up: chrome”

[Issue 346](https://github.com/w3c/webextensions/issues/346): New API: UserSettings.isOnToolbar change event

* [oliver] Just wanted to mention, seems generally supported of the event, and prefers just a new value in the data.
* [tiimothy] I would also be supportive of the event. About TypeScript syntax to sketch proposals, looks folks are in favor, and it looks readable.
* [oliver] It seems fine, though Simeon's comment might have implied additional info that we don't want to (oldValue).
* [timothy] We don't need to lock ourselves to using TypeScript, and can use it as a reference when we implement it in the browser.
* [oliver] What do you think of the proposal from Devlin, where the event receives the current state without oldValue/newValue?
* [rob] Agree with Devlin. A potential concern with offering all properties in general is when it is (computationally) expensive to gather the state of all flags. But it doesn't look too expensive to provide the full object in this case.
* [tomislav] Firefox has more than one toolbar, so we'll provide additional information in the event data.
* [simeon] Just joined. The API proposal is offering a broad API surface, to see how we can converge to a representation that offers just what's necessary. Taking inspiration from existing libraries, so that processing of the update is as stateless as possible, but obviously not required for this use case.
* [timothy] In general I agree, but in this specific case it doesn't seem too useful because we only have two values, and the old one can be inferred. But a good idea for other events like the icon path.
* [mukul] If there are multiple flag state changes, there may be a need to distinguish between updates of one flag vs multiple.
* [oliver] At the moment there is only one property, we can decide what to do when there are multiple properties later.
* [rob] When I previously said “Agree with Devlin”, I was also explicitly referring to the part where only the changed properties are included. We aren't considering including all properties in every change event.
* [oliver] So to summarize, seems we all agree to have the onUserSettingsChanged event with the single property.

[Issue 344](https://github.com/w3c/webextensions/issues/344): Regular expressions in DNR API (regexFilter)

* [timothy] [Good summary](https://github.com/w3c/webextensions/issues/344#issuecomment-1430358116) about things working/not working across implementations, most painful about Safari lacking numerical qualifiers. I'll look into this and file bugs internally to implement them.
* [rob] Summary is helpful as a starting point for a common cross-browser supported set from Safari's version. Supporting OR (|) would probably add complexity to the requirements of the regexp evaluation engine, especially when nested groups are involved.
* [timothy] Another missing thing is negative lookahead, which seems less likely to be supported because of complexities of supporting it, and none of the browsers currently do.
* [oliver] I'll look at these comments in detail and get back later.
* [rob] Let's revisit this at a later meeting.

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

* [tomislav] Firefox has a “action.theme_icons” property, but with light/dark having the opposite of what's conventional in the web platform (it was based on internal names for “dark/light text”). We plan to align with the syntax suggested in the design doc for Chrome.
* [rob] [The proposal on Chromium's issue tracker](https://github.com/w3c/webextensions/issues/229#issuecomment-1163470310) has not had any follow-up. Oliver, could you check in on that?
* [oliver] Yes.
* [rob] Does Safari support light/dark icons?
* [timothy] Not currently, but if everyone agrees then it would make sense to track this internally. Safari will auto-darkening or auto-inversion for some icons.
* [mukul] Do we want to support SVG icons instead, because they can adapt to the color somewhat?
* [timothy] Firefox and Safari already support, but not Chrome. And some of the more fancy features are not available.
* [tomislav] Similarly in Firefox, we have some limitations that prevent this to be an easy solution for light/dark icons.
* [simeon] When image assets are loaded in Chrome, the images are handled by the Skia library whose implementation does not support SVG.

[Issue 269](https://github.com/w3c/webextensions/issues/269): declarativeNetRequest API: have isUrlFilterCaseSensitive condition set to false by default

* [timothy] We recently shipped this in Safari Technology Preview.
* [rob] Firefox already supports this behavior. And Simeon has filed a crbug to track this - https://crbug.com/1414441.
* [oliver] I can follow up with the team to track that.

Status update on in-process work on API deprecation

* [simeon] I am working on docs about the deprecation process for extension APIs. I am reaching out to experienced folks in the web space for additional perspectives.
* [timothy] I think that it is useful to nail this down, for what comes next once MV3 is the current standard.

The next meeting will be on [Thursday, March 2nd, 8 AM PST (4 PM UTC)](https://everytimezone.com/?t=63ffe700,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,22 +10,23 @@ After the end of each meeting, meeting notes are published here.

## Upcoming meetings

- 2023-02-16 at 8 AM PST = https://everytimezone.com/?t=63ed7200,3c0
- 2023-03-02 at 8 AM PST = https://everytimezone.com/?t=63ffe700,3c0
- 2023-03-16 at 8 AM PST = https://everytimezone.com/?t=64125c00,3c0

## Past meetings

* 2023-02-16 ([minutes](2023-02-16-wecg.md))
* 2023-02-02 ([minutes](2023-02-02-wecg.md))
* 2023-01-19 ([minutes](2023-01-19-wecg.md))
* 2023-01-05 ([minutes](2023-01-05-wecg.md))
* 2022-12-08 ([minutes](2022-12-08-wecg.md))
* 2022-11-24 ([minutes](2022-11-24-wecg.md))

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

**2023**

* 2023-02-16 ([minutes](2023-02-16-wecg.md))
* 2023-02-02 ([minutes](2023-02-02-wecg.md))
* 2023-01-19 ([minutes](2023-01-19-wecg.md))
* 2023-01-05 ([minutes](2023-01-05-wecg.md))
Expand Down