-
Notifications
You must be signed in to change notification settings - Fork 54
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
Merge pull request #504 from w3c/meeting-2023-12-07
Publish minutes of 2023-12-07 meeting
- Loading branch information
Showing
2 changed files
with
182 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,179 @@ | ||
| # WECG Meetings 2023, Public Notes, Dec 7 | ||
|
|
||
| * Chair: Timothy Hatcher | ||
| * Scribes: Rob Wu | ||
|
|
||
| Time: 8 AM PST = https://everytimezone.com/?t=65710b00,3c0 | ||
| Call-in details: [WebExtensions CG, 7th December 2023](https://www.w3.org/events/meetings/1cc4723f-c539-4c9b-94d2-912bcc2598c9/20231207T080000/) | ||
| 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. | ||
|
|
||
| * **Carry-over from previous meetings** | ||
| * [Issue 336](https://github.com/w3c/webextensions/issues/336): Inconsistency: action.setIcon() & action.setBadgeBackgroundColor() | ||
| * [Issue 493](https://github.com/w3c/webextensions/issues/493): Support redirect-only rule in DNR | ||
| * [Issue 477](https://github.com/w3c/webextensions/issues/477): Proposal: userScripts.execute() method | ||
| * **Other new issues** | ||
| * [Issue 255 (WHATWG)](https://github.com/whatwg/compat/issues/255): Document window.browser | ||
| * [Issue 229](https://github.com/w3c/webextensions/issues/229): Extension icons for light/dark/custom theme | ||
| * [Issue 496](https://github.com/w3c/webextensions/issues/496): Proposal: Include documentId in Tab object proposal | ||
| * [Issue 497](https://github.com/w3c/webextensions/issues/497): Inconsistency: storage.managed | ||
| * [Issue 498](https://github.com/w3c/webextensions/issues/498): Proposal inconsistency: runtime.getContexts() proposal differs from Chromium implementation | ||
| * [PR 499](https://github.com/w3c/webextensions/pull/499): action.onUserSettingsChanged proposal | ||
| * **Open discussion queue (add yourself at the bottom)** | ||
| * <end of list> | ||
| * **Check-in on ongoing issues** | ||
| * None | ||
|
|
||
|
|
||
| ## Attendees (sign yourself in) | ||
|
|
||
| 1. Rob Wu (Mozilla) | ||
| 2. Oliver Dunk (Google) | ||
| 3. Timothy Hatcher (Apple) | ||
| 4. Maxim Topciu (AdGuard) | ||
| 5. Dmitriy Seregin (AdGuard) | ||
| 6. Steven McLintock (1Password) | ||
| 7. Simeon Vincent (unaffiliated) | ||
| 8. Tomislav Jovanovic (Mozilla) | ||
| 9. Benjamin Bruneau (1Password) | ||
| 10. Carlos Jeurissen (Jeurissen Apps) | ||
| 11. Jarek Samic (1Password) | ||
| 12. Mukul Purohit (Microsoft) | ||
| 13. Anton Bershanskyi | ||
| 14. Emilia Paz (Google) | ||
| 15. Solomon Kinard (Google) | ||
| 16. Tim Heflin (Keeper) | ||
| 17. Jackie Han (No affiliation) | ||
|
|
||
|
|
||
| ## Meeting notes | ||
|
|
||
| [Issue 336](https://github.com/w3c/webextensions/issues/336): Inconsistency: action.setIcon() & action.setBadgeBackgroundColor() | ||
|
|
||
| * [oliver] We weren't sure how this would interact with the tab; I'll follow up with the team. | ||
| * [timothy] I believe that Firefox and Safari already support resetting here. | ||
|
|
||
| [Issue 493](https://github.com/w3c/webextensions/issues/493): Support redirect-only rule in DNR | ||
|
|
||
| * [rob] Within one extension: When a block happens, the request is to redirect to another location. What should happen when multiple extensions are involved? Main motivation for redirecting rather than blocking is for anti-anti-adblockers. Even if we were to support the requested capability here, anti-adblockers could detect and bypass that easily. The ideal primitive here would be the ability to replace the response body/headers without a visible redirect. | ||
| * [timothy] We could do that in WebKit. | ||
| * [rob] Let's return the question to the issue: would the proposal above be the preferred solution? | ||
| * [oliver] In Chrome we're introducing responseHeader matching, it would be strange if . | ||
| * [maxim] In some extensions, if a request might be blocked we first check redirect rules before applying the block. This happens with JavaScript blocking via webRequest. | ||
| * [timothy] That's probably more difficult with DNR. That's why it might be better with a more specific rule type. Makes it more clear that there's a specific set of actions being taken rather than complicating interactions between multiple different actions. | ||
| * [oliver] | ||
| * [timothy] Current WebKit implementation ends evaluation on first match. Redirect would have to be sorted above everything else in order for that to take precedence. | ||
| * [oliver] That could be a solution for extensions. | ||
| * [simeon] That would require generating rules with the correct priority order, right? | ||
| * [oliver] Yes, could be auto-generated by the filterlist -> DNR conversion process. | ||
| * [maxim] I can check if this would work, but the current situation is that we only want to redirect if the request would be blocked. We may not be able to create a set of rules to match these conditions. | ||
|
|
||
| [Issue 477](https://github.com/w3c/webextensions/issues/477): Proposal: userScripts.execute() method | ||
|
|
||
| * [rob] Asked reporter for use cases. Request is for the ability to execute arbitrary strings rather than triggering execution of existing scripts. This is more of a policy question – the user scripts API is designed to allow execution of arbitrary code, basically restoring tabs.executeScripts+code. | ||
| * [oliver] Yes, this was in the proposal of the original API. I'll discuss this with the team. | ||
| * [simeon] In terms of API design; Having user scripts managers register and execute is the broader pattern we should encourage, rather than executing arbitrary code at runtime. | ||
| * [timothy] The register method already supports arbitrary code, why is this proposal needed? | ||
| * [oliver] When we wrote the proposal, the use case that we had in mind is to run code on action click, rather than needing a wrapper around some code that gets always injected. | ||
| * [emilia] Registered scripts run anywhere, provided that host permissions match. It's up to the store policy to enforce reasonable API usage. execute() would have similar enforcements. | ||
| * [simeon] I don't think it's a new issue. My thought here is more about encouraging specific usage patterns and making it more clear when the API is not being used as intended. | ||
| * [rob] If you have both a registration and method of triggering a registration on demand, then that could be used to achieve the behavior of “execute()”. To execute on a specific frame, the registration needs to support tabId, frameId and/or documentId in order to target the correct execution context. Do we want to encourage the declarative pattern, or do we want to port the old API (tabs.executeScript+code) from MV2 to MV3? | ||
| * [oliver] A third option I see is registering a script that doesn't match anywhere, and then a method to force execution of it whole ignoring the conditions. | ||
| * [rob] If it doesn't match, then it shouldn't execute. That was a design flaw in tabs.executeScript ([issue 8](https://github.com/w3c/webextensions/issues/8)). | ||
| * [oliver] We would relax the matching for an explicit execute call. | ||
| * [rob] That leads to situations where we may end up executing on the wrong document, such as if a navigation occurs between call and execution. | ||
| * [timothy] Let's continue to discuss async. | ||
|
|
||
| [Issue 255 (WHATWG)](https://github.com/whatwg/compat/issues/255): Document window.browser | ||
|
|
||
| * [oliver] Short summary: at TPAC we had a short discussion on supporting the browser namespace in Chrome. The start is the need to specify the browser namespace somewhere first. This issue was opened to serve that purpose. | ||
| * [rob] Meeting notes starting at “browser namespace” in https://github.com/w3c/webextensions/blob/main/_minutes/2023-09-11-2023-09-14-tpac-extra.md | ||
| * [tomislav] Saw this yesterday and started discussing it with standards folks at Mozilla. I will write a comment and follow up with a standards position at Mozilla if appropriate. Will aim to do this within the next week. | ||
| * [rob] Should we create a WECG issue to keep track of the issue in the whatwg/compat repo? | ||
| * [timothy] We have the old browser neutral naming issue ([issue 113](https://github.com/w3c/webextensions/issues/113)). | ||
| * [rob] That has evolved to cover many other topics. | ||
| * [tomislav] Since Dominic is at Google, can you post a comment on the issue indicating support on the Safari side? | ||
| * [timothy] Yes, Tess or I should be able to add a comment. | ||
|
|
||
| [Issue 229](https://github.com/w3c/webextensions/issues/229): Extension icons for light/dark/custom theme | ||
|
|
||
| * [solomon] I had a proposal from a while back. While implementing this, I came across a concern that needs some additional discussion. If dark mode is specified, but no light, or dark but no light, what should we fall back to? | ||
| * [timothy] I think once a developer is using the theme icons keys, I don't think fallback should happen piecemeal to default icons. That keeps implementation cleaner & self contained. If a dev leaves out light or dark, it will be more obvious for them to fix. If theme icons are missing entirely, fallback to non-theme icons should happen. | ||
| * [oliver] This isn't theme icons. That's another thing currently supported by Firefox. “dark” and “light” under icons is what we're currently discussing. | ||
| * [oliver] Example: | ||
| ``` | ||
| "icons": { | ||
| "dark": { | ||
| "128": "icons/128_dark.png" | ||
| }, | ||
| "light": { | ||
| "128": "icons/128_light.png" | ||
| }, | ||
| "128": "icons/128.png" | ||
| }, | ||
| ``` | ||
| * [carlos] I recently tested icons.dark and icons.light and this prevents an extension from loading in Chrome currently. This issue has been discussed in the group before and we were more leaning towards implementing theme_icons as implemented by Firefox right now. This would allow an implementation that is backwards compatible. Maybe in MV4 we could go with a more streamlined version. If we add something like dark/light, it would be good to support something like SVG from the start. | ||
| * [timothy] I'd prefer to do SVG support from the start. Backwards compatibility concerns are definitely there when we're reusing the same key. Safari will ignore it, but a JS exception will be thrown if you try to call action.setIcon() in Safari with a non-numeric key. I expect Chrome will be more strict than most with this kind of thing. | ||
| * [oliver] For clarity, are you supportive of theme_icons or light/dark in | ||
| * [timothy] The issue is unclear. Preference is to use a new key. | ||
| * [oliver] Firefox reps, I believe you were planning to remove theme_icons, correct? | ||
| * [rob] The issue with theme_icons in Firefox is that the meaning of “dark” and “light” deviate from the current conventions on the web platform. So on Firefox's end we are willing to support icons. | ||
| * [timothy] One potential issue with “icons” is that numeric keys are expected. | ||
| * [rob] That's my big concern. Firefox also does not support non-numeric keys either and refuses to load the extension/manifest if non-numeric keys are present in “icons”. “Theme_icons” supports dark/light/size and only warns about unrecognized keys (no hard error). | ||
| * [timothy] We don't currently support anything other than the auto dark mode thing we currently do | ||
| * [tomislav] Seems there's consensus around the idea of supporting light and dark icons and mutual concerns around backwards compatibility. Suggest we move bikeshedding on the specifics into async conversation in the issue. | ||
| * [solomon] | ||
| ``` | ||
| "icons": { | ||
| "dark": "icons/128_dark.png", | ||
| "light": "icons/128_light.png", | ||
| "*": "icons/128.png" | ||
| } | ||
| ``` | ||
| * [timothy] I think you're referring to an SVG value as a string, which isn't supported by Chrome. The snippet you pasted is supported by Firefox and Safari. | ||
| * _(Solomon left the meeting)_ | ||
| * [rob] Oliver, please follow up with Solomon (Chrome). Suggest bringing a hard proposal we can discuss in detail, potentially async. | ||
|
|
||
| [Issue 496](https://github.com/w3c/webextensions/issues/496): Proposal: Include documentId in Tab object proposal | ||
|
|
||
| * [timothy] Only Chrome supports documentId today; I think that it is a decent idea. There is always the possibility of the tab having navigated etc, but that is already covered by APIs rejecting calls when the documentId is invalid. | ||
| * [anton] Concern about the chattiness of the API due to documentId transitions. | ||
| * [timothy] tabs.onUpdated is already very chatty when the tab content changes. | ||
| * [rob] Main motivation for this request is that webNavigation has a permission warning. Tabs API is already available by default without special permissions. That's why this request adds more to the kitchen sink of this API. | ||
| * [timothy] Tabs is inherently a generic concept, not too hesitant about that. | ||
| * [oliver] I was initially supportive, because I like seeing documentId added everywhere. But now I think that we should think a bit more about it. | ||
| * [simeon] In general, I feel that the chattiness concerns. I would like to explore how we could make filters more flexible in general. | ||
| * [rob] documentId is not tab-specific; The context concept (from runtime.getContexts) could potentially be used instead (or in addition to) the tabs/webNavigation API. | ||
| * [tomislav] Would like to follow up on Timothy's comment about coalescing tab events. | ||
| * [oliver] Not aware of this behavior in Chromium if it does exist | ||
| * [tomislav] We've had some performance issues with event dispatch. I will follow up. | ||
| * [timothy] tab.onUpdated event coalesces on 25ms intervals. Makes it possible for multiple updates that might occur in quick succession, such as navigation, triggering an atomic set of updates. | ||
| * [tomislav] Concerned that multiple events in an atomic set could be spread over updates. I will need to think on this and follow up with a proposal. | ||
|
|
||
| [Issue 497](https://github.com/w3c/webextensions/issues/497): Inconsistency: storage.managed | ||
|
|
||
| * [rob] Firefox's API is inspired by chrome, but we don't have strict enforcement of schema. | ||
| * [oliver] Having configuration stored in different locations is a browser specific consideration. Similar to native messaging. | ||
| * [rob] Part of the problem was that the schema validation is not defined. Firefox already has multiple schema validators and there was no desire to implement another one specific to this API. (more details in https://bugzilla.mozilla.org/show_bug.cgi?id=1771731) | ||
| * [tomislav] Potential security concerns as this could balloon both in CPU and memory usage. | ||
| * [rob] We could align on specific things like error propagation from API calls. Beyond that, not clear how much benefit there is on alignment. Issue is valid, but in its current form it doesn't seem to be a high priority for any of us. | ||
| * [oliver] Agreed. | ||
| * [timothy] Agreed. | ||
|
|
||
| [Issue 498](https://github.com/w3c/webextensions/issues/498): Proposal inconsistency: runtime.getContexts() proposal differs from Chromium implementation | ||
|
|
||
| * [rob] Discuss this async. | ||
|
|
||
| [PR 499](https://github.com/w3c/webextensions/pull/499): action.onUserSettingsChanged proposal | ||
|
|
||
| * [emilia] Proposal based on an already-discussed issue and accepted by the browser vendors. Pretty straightforward proposal to add an event. A comment was added to mention the addListener/removeListener format. That was not an intentional change, I intent to use the Event pattern for this API. | ||
| * [timothy] As long as it follows the event pattern, I don't have any objections to it. | ||
| * [tomislav] Same. | ||
|
|
||
| (ran out of time, 4 items moved to the next meeting) | ||
|
|
||
| The next meeting will be on [Thursday, January 4th, 8 AM PST (4 PM UTC)](https://everytimezone.com/?t=6595f500,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