-
Notifications
You must be signed in to change notification settings - Fork 56
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
Publish minutes of 2024-02-29 meeting
- Loading branch information
Showing
2 changed files
with
167 additions
and
2 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,164 @@ | ||
| # WECG Meetings 2024, Public Notes, Feb 29 | ||
|
|
||
| * Chair: Timothy Hatcher | ||
| * Scribes: Rob Wu | ||
|
|
||
| Time: 8 AM PST = https://everytimezone.com/?t=65cd5400,3c0 | ||
| Call-in details: [WebExtensions CG, 29th February 2024](https://www.w3.org/events/meetings/7aa2fdfc-f21b-4a2c-ba42-d1b628aa5140/) | ||
| Zoom issues? Ping @zombie (Tomislav Jovanovic) in [chat](https://github.com/w3c/webextensions/blob/main/CONTRIBUTING.md#joining-chat) | ||
|
|
||
|
|
||
| ## Agenda: [discussion in #549](https://github.com/w3c/webextensions/issues/549), [github issues](https://github.com/w3c/webextensions/issues) | ||
|
|
||
| The meeting will start at 3 minutes after the hour. | ||
|
|
||
| See [issue 531](https://github.com/w3c/webextensions/issues/531) for an explanation of this agenda format. | ||
|
|
||
| * **Announcements** (2 minutes) | ||
| * **Triage** (15 minutes) | ||
| * [Issue 533](https://github.com/w3c/webextensions/issues/533): Enhance browser.storage.local to allow storing binary data directly | ||
| * [Issue 534](https://github.com/w3c/webextensions/issues/534): Inconsistency with indexedDB in browser extensions | ||
| * _(ran out of time for this section of the meeting; the following was not discussed)_ | ||
| * [Issue 547](https://github.com/w3c/webextensions/issues/547): Proposal: document `browser.storage.managed` initialization semantics and provide initialization event | ||
| * **Timely issues** (10 minutes) | ||
| * [Issue 539](https://github.com/w3c/webextensions/issues/539): Proposal: RegisteredContentScript.tabIds and RegisteredContentScript.excludeTabIds properties to filter injection | ||
| * [Issue 536](https://github.com/w3c/webextensions/issues/536): Proposal: RegisteredContentScript.func and RegisteredContentScript.args (similar to ScriptInjection) | ||
| * _(ran out of time for this section of the meeting; the following was not discussed)_ | ||
| * [Issue 538](https://github.com/w3c/webextensions/issues/538): Proposal: RegisteredContentScript.workers property to inject WorkerScope(s) | ||
| * **Check-in on existing issues** (20 minutes) | ||
| * [PR 546](https://github.com/w3c/webextensions/pull/546): Determine the nuances of aliasing `chrome` and `browser` | ||
| * [PR 540](https://github.com/w3c/webextensions/pull/540): Add userScripts.execute() API proposal | ||
| * [PR 529](https://github.com/w3c/webextensions/pull/529): Add permissions.requestSiteAccess() API proposal | ||
| * [PR 542](https://github.com/w3c/webextensions/pull/542): Add content scripts section in specification | ||
| * [PR 543](https://github.com/w3c/webextensions/pull/543): Add proposal processes | ||
| * [Issue 302](https://github.com/w3c/webextensions/issues/302): [Check in on critical functionality regression in MV3/DNR](https://github.com/w3c/webextensions/issues/549#issuecomment-1947352284) | ||
|
|
||
|
|
||
| ## Attendees (sign yourself in) | ||
|
|
||
| 1. Rob Wu (Mozilla) | ||
| 2. Patrick Kettner (Google) | ||
| 3. Timothy Hatcher (Apple) | ||
| 4. Oliver Dunk (Google) | ||
| 5. Giorgio Maone (NoScript, Tor) | ||
| 6. Tomislav Jovanovic (Mozilla) | ||
| 7. Carlos Jeurissen (Jeurissen Apps) | ||
| 8. Richard Worth (Capital One) | ||
| 9. Mukul Purohit (Microsoft) | ||
| 10. Emilia Paz (Google) | ||
| 11. Todd Schiller (PixieBrix) | ||
| 12. David Johnson (Apple) | ||
| 13. Kiara Rose (Apple) | ||
| 14. Anton Bershanskyi | ||
| 15. Simeon Vincent (unaffiliated) | ||
| 16. Tim Heflin (Keeper) | ||
|
|
||
|
|
||
| ## Meeting notes | ||
|
|
||
| [Issue 533](https://github.com/w3c/webextensions/issues/533): Enhance browser.storage.local to allow storing binary data directly | ||
|
|
||
| * [timothy] Request to support typed arrays and such. IndexedDB does not persist across sessions in private browsing. | ||
| * [tomislav] This should work with structured cloning. Supportive of it. | ||
| * [simeon] Historically Chrome has been hesitant about supporting non-string values. IndexedDB is preferable for JS objects. | ||
| * [rob] IndexedDB is not persistent when incognito:split is used in Chrome. | ||
|
|
||
| [Issue 534](https://github.com/w3c/webextensions/issues/534): Inconsistency with indexedDB in browser extensions | ||
|
|
||
| * [timothy] In Safari we change the host name on every relaunch of the browser. Would like to not do that. | ||
| * [patrick] The expectation for incognito is that the data is not persistent when the incognito session ends. | ||
| * [rob] Does Safari support incognito:split? | ||
| * [timothy] We do not. | ||
| * [rob] Firefox does not support incognito:split either. | ||
| * [timothy] indexedDB in private browsing in Safari is in-memory and lost upon exit. | ||
| * [simeon] It would be sensible to keep extension data of indexedDB across sessions as the extension is functioning as part of the browser. | ||
| * [rob] Would browsers be comfortable persisting data across incognito sessions? | ||
| * [timothy] I think this only applies to Chromium: only they support split mode. | ||
| * [rob] Firefox also has “Never remember history” feature that enables permanent private browsing mode, where the extension (and its background script) runs in private browsing mode. | ||
| * [oliver] Need to follow up with Chrome. | ||
|
|
||
| [Issue 547](https://github.com/w3c/webextensions/issues/547): Proposal: document `browser.storage.managed` initialization semantics and provide initialization event | ||
|
|
||
| * (ran out of time for this section of the meeting; not discussed) | ||
|
|
||
| [Issue 539](https://github.com/w3c/webextensions/issues/539): Proposal: RegisteredContentScript.tabIds and RegisteredContentScript.excludeTabIds properties to filter injection | ||
|
|
||
| * [timothy] Registered content scripts persist, tabIds are ephemeral. Doesn't fit together. | ||
| * [rob] Scripts do not persist when persistAcrossSessions:false is used. Main value is in declaring the script before loading a document. | ||
| * [timothy] If we were to support this, then persistAcrossSessions:true should not be allowed. | ||
| * [giorgio] What Rob said. | ||
| * [timothy] Is tabId the right granularity? Why not documentId? | ||
| * [giorgio] For my use case yes. | ||
| * [rob] documentId only exists when the document has loaded, in which case scripting.executeScript could be used instead. | ||
| * [giorgio] Use case has the toggle apply across navigation and origins. | ||
| * [rob] If we were to support this, would we include automatic garbage collection of scripts that cannot match any tab? | ||
| * [timothy] I think so, yes. Would be onerous for extensions to implement and if they don't we have to do more work. | ||
| * [oliver] It seems strange to automatically change the script when a tab closes. | ||
| * [rob] Not individually removing tabIds, but unregistering the script when it cannot execute anywhere. | ||
| * [rob] Firefox: in favor | ||
| * [timothy] Safari: neutral/in favor | ||
| * [oliver] Chrome: tabId sounds useful, hesitant with automagic gc. | ||
|
|
||
| [Issue 536](https://github.com/w3c/webextensions/issues/536): Proposal: RegisteredContentScript.func and RegisteredContentScript.args (similar to ScriptInjection) | ||
|
|
||
| * [giorgio] Passing parameters to scripts, synchronously. | ||
| * [rob] I support the requested capability because extensions don't have good alternatives. | ||
| * [timothy] Also supportive, func/args can be stored. | ||
| * [simeon] First impression, | ||
| * [oliver] Parametrizing scripts is something we've discussed before. This could be a halfway step. | ||
| * [rob] What should happen with func/args when persistAcrossSessions:true is used when an extension is update? “files” param is obvious, the file exists or it does not. In case of “func”, when an extension is updated, the existence of func is no longer obvious. | ||
|
|
||
| [Issue 538](https://github.com/w3c/webextensions/issues/538): Proposal: RegisteredContentScript.workers property to inject WorkerScope(s) | ||
|
|
||
| * (ran out of time for this section of the meeting; not discussed) | ||
|
|
||
| [PR 546](https://github.com/w3c/webextensions/pull/546): Determine the nuances of aliasing `chrome` and `browser` | ||
|
|
||
| * [patrick] Need to catch up on Rob's feedback. | ||
| * [timothy] I still think that they should be direct aliases. | ||
| * [rob] I posted the question of whether we want them to \_not\_ be aliases. (concern). My proposal is to make them aliases to address this problem. | ||
| * [patrick] We want to drop certain properties (e.g. loadTimes) from the browser global. | ||
| * [tomislav] If the group agreed on using a property name in browser that chrome already has usage of, would we still be able to use it? | ||
| * [patrick] If we renamed an API such as .csi, that might apply, but that seems unlikely. There are also a number of extensions that use `chrome` to feature detect Chrome. | ||
|
|
||
| [PR 540](https://github.com/w3c/webextensions/pull/540): Add userScripts.execute() API proposal | ||
|
|
||
| * [timothy] Proposal seems fine, no objections. | ||
| * [rob] I approved it before. | ||
|
|
||
| [PR 529](https://github.com/w3c/webextensions/pull/529): Add permissions.requestSiteAccess() API proposal | ||
|
|
||
| * [timothy] Hesitant from Safari side, after discussion with Devlin, decided to include “url” to allow the API to work in Safari. If you don't already have access to the tab, the extension doesn't know what's in the tab. | ||
| * [emilia] I have updated the proposal based on your feedback, and on Chrome's side tabId or documentId has to be specified, url is also permitted. Other change is method rename since the removeSiteAccessRequest method was added, and a return value was added to see the outcome. | ||
| * [timothy] When the API adds a request, it is not clear whether the URL is shown or even shown at all. Also suggest renaming “showSiteAccessRequest” to “addSiteAccessRequest” because that matches Safari's behavior more closely. | ||
| * [tomislav] tabId, url, etc., is that an OR? | ||
| * [emilia] Everything passed is required. | ||
| * [tomislav] Is tabId required? Safari seems to prefer url without requiring tabId. | ||
| * [emilia] tabId or documentId is required. | ||
| * [timothy] We won't support tabId. | ||
| * [emilia] If the model is better to require tabId or documentId or url, then I can also consider that. | ||
| * [tomislav] Specifying that only one of them can be used would avoid the issue of “tabId+url” resulting in matching url (and ignoring tabId, in Safari) vs “tabId+url” resulting in matching tabId AND url (in Chrome). | ||
| * [oliver] How to feature detect that? | ||
| * [simeon] Rob mentioned before that an extension can call the API and catch an error. As a JS developer it would be nice to be able to feature-detect without try-catch. | ||
| * [timothy] Would be nice if the object accepts unrecognized properties without the API throwing. | ||
| * [rob] That is inconsistent with the extension API. If you'd like to go that direction, a new property that accepts some kind of descriptor that explicitly allows objects with any properties would be more consistent with the existing extension API behavior. | ||
|
|
||
| [PR 542](https://github.com/w3c/webextensions/pull/542): Add content scripts section in specification | ||
|
|
||
| * [oliver] Please take a look and provide feedback. | ||
|
|
||
| [PR 543](https://github.com/w3c/webextensions/pull/543): Add proposal processes | ||
|
|
||
| * [timothy] Opened by Devlin, a proposal template and guide to write a proposal. | ||
| * [rob] I posted a review, generally looks good to merge. | ||
| * [simeon] Looks solid. | ||
|
|
||
| [Issue 302](https://github.com/w3c/webextensions/issues/302): [Check in on critical functionality regression in MV3/DNR](https://github.com/w3c/webextensions/issues/549#issuecomment-1947352284) | ||
|
|
||
| * [timothy] Blocking webRequest use case, cannot block/redirect based on URL parameters. | ||
| * [alexei] Undocumented gap that affects a class of privacy/link cleaning extensions. Would like to raise attention to this to make sure that this is addressed before Chrome's June 2024 deadline. | ||
| * [oliver] Supportive of addressing this use case. Not considered a blocker for adjusting Chrome's June timeline though. | ||
| * [alexei] If it is not a blocker, would you still consider it a real issue? | ||
| * [patrick] Although some prominent extensions use it, its overall usage across all extensions is relatively low. | ||
|
|
||
| The next meeting will be on [Thursday, March 14th, 8 AM PST (4 PM UTC)](https://everytimezone.com/?t=65f23e00,3c0) |
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters