-
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 #602 from w3c/meeting-2024-04-25
Publish minutes of 2024-04-25 meeting
- Loading branch information
Showing
2 changed files
with
183 additions
and
1 deletion.
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 2024, Public Notes, Apr 25 | ||
|
|
||
| * Chair: Timothy Hatcher | ||
| * Scribes: Rob Wu | ||
|
|
||
| Time: 8 AM PDT = https://everytimezone.com/?t=66299d00,384 | ||
| Call-in details: [WebExtensions CG, 25th April 2024](https://www.w3.org/events/meetings/a97adab8-e1ae-4a2b-85cf-e6b6d3d35f00/20240425T080000/) | ||
| Zoom issues? Ping @zombie (Tomislav Jovanovic) in [chat](https://github.com/w3c/webextensions/blob/main/CONTRIBUTING.md#joining-chat) | ||
|
|
||
|
|
||
| ## Agenda: [discussion in #590](https://github.com/w3c/webextensions/issues/590), [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 583](https://github.com/w3c/webextensions/issues/583): Proposal: Allow globs for the contextMenus API instead of just URL patterns | ||
| * [Issue 591](https://github.com/w3c/webextensions/issues/591): Proposal: add new browser.tabs.waitForTab(tabId: number) that will wait for tab to load | ||
| * [Issue 592](https://github.com/w3c/webextensions/issues/592): Proposal: Add support for setting the main context menu icon | ||
| * **Timely issues** (10 minutes) | ||
| * [Issue 584](https://github.com/w3c/webextensions/issues/584): Add change history to charter | ||
| * **Check-in on existing issues** (20 minutes) | ||
| * [PR 560](https://github.com/w3c/webextensions/pull/560): Proposal: Multiple user script worlds | ||
| * [PR 569](https://github.com/w3c/webextensions/pull/569): Add getOSLanguage proposal | ||
| * [PR 585](https://github.com/w3c/webextensions/pull/585): Add a proposal for dark mode extension icons | ||
| * [PR 587](https://github.com/w3c/webextensions/pull/587): Proposal: downloads.getFileHash() | ||
| * [PR 598](https://github.com/w3c/webextensions/pull/598): Proposal: manifest key trial_tokens | ||
| * [Issue 489](https://github.com/w3c/webextensions/issues/489): Proposal: Re-evaluate userScript and userStyle API | ||
| * [Issue 34](https://github.com/w3c/webextensions/issues/34): Request: high precise timer | ||
|
|
||
|
|
||
| ## Attendees (sign yourself in) | ||
|
|
||
| 1. Rob Wu (Mozilla) | ||
| 2. David Johnson (Apple) | ||
| 3. Oliver Dunk (Google) | ||
| 4. Timothy Hatcher (Apple) | ||
| 5. Carlos Jeurissen (Jeurissen Apps) | ||
| 6. Solomon Kinard (Google) | ||
| 7. Anton Bershanskyi | ||
| 8. Rémi Pujo (Dashlane) | ||
| 9. Alisa Tikhova (eyeo) | ||
| 10. Kiara Rose (Apple) | ||
| 11. Elijah Sawyers (Apple) | ||
| 12. Simeon Vincent (Mozilla) | ||
| 13. Jackie Han (no affiliation) | ||
| 14. Mukul Purohit (Microsoft) | ||
| 15. Steven McLintock (1Password) | ||
| 16. Jarek Samic (1Password) | ||
| 17. Tim Heflin (Keeper) | ||
| 18. Tomislav Jovanovic (Mozilla) | ||
| 19. Richard Worth (Capital One) | ||
|
|
||
|
|
||
| ## Meeting notes | ||
|
|
||
| Announcement: San Diego in-person meeting notes published | ||
|
|
||
| * [rob] Meeting notes for the San Diego in-person meetup ([#525](https://github.com/w3c/webextensions/issues/525)) have been published. For an overview of the 66 issues, expand the spoiler at the bottom of the PR text at https://github.com/w3c/webextensions/pull/599. | ||
| * [2024-03-18-san-diego-meetup.md](https://github.com/w3c/webextensions/blob/main/_minutes/2024-03-18-san-diego-meetup.md) | ||
| * [2024-03-19-san-diego-meetup.md](https://github.com/w3c/webextensions/blob/main/_minutes/2024-03-19-san-diego-meetup.md) | ||
| * [2024-03-20-san-diego-meetup.md](https://github.com/w3c/webextensions/blob/main/_minutes/2024-03-20-san-diego-meetup.md) | ||
|
|
||
| [Issue 583](https://github.com/w3c/webextensions/issues/583): Proposal: Allow globs for the contextMenus API instead of just URL patterns | ||
|
|
||
| * [timothy] Supportive of globs even though we don't support globs for anything yet. | ||
| * [simeon] What are the globs we're talking about? | ||
| * [rob] Match globs, basically wildcards. | ||
| * [timothy] Rob provided feedback in the issue. | ||
| * [rob] I asked for use cases and questioned the value of this API addition. The provided use case was making it easier for extension users to provide a pattern and it to work automatically. For that use case, I would expect extensions to format the user-provided input as a match pattern. | ||
| * [rob] Firefox position is neutral at most, unless there is cross browser implementor interest, we're not going to pursue this. | ||
| * [simeon] Wondering whether there is a safe set of matching algorithms (e.g. regexp is expensive) that we should support. | ||
| * [rob] Concern over bloating the API, every pattern type would add two more pairs of properties like documentUrlPatterns and targetUrlPatterns. | ||
| * [rob] Chrome's perspective? | ||
| * [oliver] Need to follow-up, but likely not a priority either. | ||
|
|
||
| [Issue 591](https://github.com/w3c/webextensions/issues/591): Proposal: add new browser.tabs.waitForTab(tabId: number) that will wait for tab to load | ||
|
|
||
| * [timothy] This could already be implemented with extension APIs today, but having a general way to do this would be useful. | ||
| * [rob] Supportive. Common pattern in unit tests and extensions, but concerned about time-of-check to time-of-use (TOCTOU) issues. Integrate tabId/frameId/documentId? | ||
| * [oliver] Also supportive, and seen in Chrome's tests. Needs a fleshed out proposal. | ||
| * [timothy] Interested in the general concept. | ||
| * [simeon] What if the tab does not finish loading? | ||
| * [rob] That is already an existing problem with the extension-implemented version of this; The browser can detect this more reliably and reject the API call if needed. | ||
| * [rob] or include a timeout parameter. | ||
| * [simeon] Talking about timeouts, web APIs have AbortController to enable callers to cancel the API call. | ||
| * [oliver] What about redirects? | ||
|
|
||
| [Issue 592](https://github.com/w3c/webextensions/issues/592): Proposal: Add support for setting the main context menu icon | ||
|
|
||
| * [timothy] Browsers often create a top-level menu item with submenu items if the extension has more than one top-level menu item. This top-level item does not get an icon by default, and there is no way for the extension ton control it. | ||
| * [rob] Firefox allows extensions to change icons, but the icon of the top-most menu item is always from the manifest. | ||
| * [oliver] Solomon, since you've worked in this area, do you know more? | ||
| * [solomon] Is there a standard? | ||
| * [timothy] Safari supports same API as Firefox, overlaps with dark icons mode proposal. | ||
| * [rob] contextMenus.create and contextMenus.update accept an icons property - https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/WebExtensions/API/menus/create#icons | ||
| * [rob] The top-level icon cannot be modified out of caution about extensions dynamically changing them and confusing the user. | ||
| * [oliver] Same concern about the icon, but not as big of a concern. | ||
| * [rob] Chrome - there are two questions here: (1) whether Chrome is supportive of a way to update submenu extension icons, and (2) whether to support that even for the top-level menu item. Could you get answer to these questions? | ||
| * [oliver] Yes, I'll follow up. | ||
|
|
||
| [Issue 584](https://github.com/w3c/webextensions/issues/584): Add change history to charter | ||
|
|
||
| * [simeon] I opened it but forgot to update it. I'll assign this to myself. | ||
| * [oliver] I'm supportive, go ahead. | ||
|
|
||
| [PR 560](https://github.com/w3c/webextensions/pull/560): Proposal: Multiple user script worlds | ||
|
|
||
| * [rob] I have approved it, one minor typo. | ||
| * [timothy] I'll read over it. I did not have initial concerns; we haven't implemented the API yet so we don't have a lot of feedback. | ||
|
|
||
| [PR 569](https://github.com/w3c/webextensions/pull/569): Add getOSLanguage proposal | ||
|
|
||
| * [carlos] I raised this in the W3C internationalization WG. There are two use case, list of system languages, and the language used by the system. I'll wait for feedback from the internationalization group so we can move on for now. | ||
|
|
||
| [PR 585](https://github.com/w3c/webextensions/pull/585): Add a proposal for dark mode extension icons | ||
|
|
||
| * [timothy] Getting pretty close. I took a look yesterday. | ||
| * [solomon] Appreciate feedback and robust feedback. I think that I've addressed all feedback so far, and Oliver asked Rob to take a final look. I also need to sign up as a member in order to be able to get the PR merged. | ||
| * [simeon] I looked at the PR yesterday, one thing stood out to me - the sketch of JSON with accepted values. I considered adding a TypeScript definition of it. Wondering whether the group is interested in TypeScript or WebIDL? | ||
| * [solomon] When I started this proposal, the proposal started with my own dialect, then I switched to IDL, and ultimately to TypeScript. TypeScript seems easy to understand to me. | ||
| * [oliver] Unless anyone feels strongly, let's not block this PR on the syntax. | ||
| * [timothy] I don't have strong preferences on the syntax. | ||
| * [rob] As long as it is understandable, I don't mind the exact syntax. | ||
|
|
||
| [PR 587](https://github.com/w3c/webextensions/pull/587): Proposal: downloads.getFileHash() | ||
|
|
||
| * [anton] Basically have one approval (from Rob). (inaudible) | ||
| * [oliver] Open thread on the PR, if the downloads.getFileHash permission has been requested, can you call the API? | ||
| * [anton] (written) Sub-permissions work a bit differently across browsers: Firefox requires both "downloads" and "downloads.open" to call downloads.open() method. I do not have a strong opinion on this. Personally, I would be more happy with the way Chrome does it (since more fine-grained permissions carry greater agency for the user/user-agent). Would be nice to discuss this during the call today. | ||
| * [rob] In Firefox you would need permissions for the namespace (downloads) and downloads.getFileHash. | ||
| * [oliver] Are you interested in changing this? Would be nice to have scoped permissions. | ||
| * [rob] I have no strong opposition to this. Is there a precedent for this? | ||
| * [timothy] Maybe DNR? | ||
| * [oliver] That is intentional. | ||
| * [rob] I'll think about this async and comment on the PR. | ||
| * [rob] And other browser vendors, please put an approval on this PR if you approve. | ||
| * [timothy] Since we don't support the downloads API, I'll leave the approval to Chrome. | ||
|
|
||
| [PR 598](https://github.com/w3c/webextensions/pull/598): Proposal: manifest key trial_tokens | ||
|
|
||
| * [anton] I've implemented it in Chrome. Created proposal based on [issue 454](https://github.com/w3c/webextensions/issues/454). | ||
| * [tomislav] I'll take a look. | ||
|
|
||
| [Issue 489](https://github.com/w3c/webextensions/issues/489): Proposal: Re-evaluate userScript and userStyle API | ||
|
|
||
| * [timothy] Re-proposed for the agenda; I personally agree with this, and it would have been nice if the userScripts API was part of the scripting namespace. | ||
| * [rob] What was the reason for raising this issue again? | ||
| * [timothy] Not sure, no specifics were provided in the request ([comment in agenda](https://github.com/w3c/webextensions/issues/590#issuecomment-2051267561)). But I think that the ship has sailed already. | ||
| * [oliver] If there was a more specific ask, then we could consider the request. | ||
| * [timothy] Looks like CSS missing from the userScripts API is a big missing thing. | ||
| * [simeon] Adding CSS to userScripts is a possibility for the future. | ||
| * [rob] In terms of behavioral differences, supporting css in the API could result in the guarantee of the stylesheet being applied before script execution. | ||
|
|
||
| [Issue 34](https://github.com/w3c/webextensions/issues/34): Request: high precise timer | ||
|
|
||
| * [jackie] alarms API is imprecise. Some use cases don't care about slight inaccuracies, others do care. My proposal is for browsers to provide a way to make the alarm more precise, maybe through a new permission. | ||
| * [oliver] I think that this is more of a Chromium issue than an API issue. What timer resolution are you looking at? 1 second? One millisecond? | ||
| * [jackie] One second is enough. | ||
| * [timothy] I think that there may still be some confusion here. Jackie is mentioning that if multiple timers are set, that the timers may shift. I'm not sure if this could be solved in general, e.g. if event page wakeup takes more time, then the listener fires late. | ||
| * [oliver] The shift in Chrome is due to the implementation enforcing a minimum between timers to prevent extensions from scheduling multiple timers. I don't think that there is any throttling in other browsers, is that the case? | ||
| * [rob] Yes. | ||
| * [timothy] No throttling in Safari either. | ||
| * [oliver] We're looking into lowering the timer limit from 30 to 1 second. So basically what you are asking for Jackie, but without requiring permission changes. | ||
| * [timothy] When lowering the limit was discussed at the San Diego meetup, I think that Devlin (Chrome) expressed reluctance to lowering it, didn't he? | ||
| * See “Issue 34” in the [meeting minutes of 2024-03-20-san-diego-meetup.md](https://github.com/w3c/webextensions/blob/main/_minutes/2024-03-20-san-diego-meetup.md) | ||
| * [oliver] We have had more discussions, and the conclusion is probably not that concerning, but we want to collect data first to confirm that it would not have a negative performance impact. | ||
| * [anton] I've looked at Chrome's implementation and it serializes all timers and persists it. That could potentially be optimized. | ||
| * [rob] Since Chrome hasn't supported short timers before, could you consider changing the default of short timers, to not persist by default? That would reduce the performance concerns. | ||
| * [oliver] Haven't discussed before. | ||
| * [tomislav] We've discussed non-persistent timers before in TPAC, and that it would be nice to have different persistency through options. | ||
| * [rob] Discussed before at [Issue 406](https://github.com/w3c/webextensions/issues/406): Inconsistency: Persistence of alarms in browser.alarms API | ||
| * [rob] Since Chrome doesn't support short timers yet, it would not be a breaking change to change the default. Firefox does currently not persist the alarms. | ||
| * [timothy] Safari doesn't persist either. | ||
| * [oliver] I'll bring it up. We're also definitely supportive of persistAcrossSessions flag in general. | ||
|
|
||
| The next meeting will be on [Thursday, May 9th, 8 AM PDT (3 PM UTC)](https://everytimezone.com/?t=663c1200,384) |
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