diff --git a/_minutes/2023-05-25-wecg.md b/_minutes/2023-05-25-wecg.md new file mode 100644 index 00000000..c8c31235 --- /dev/null +++ b/_minutes/2023-05-25-wecg.md @@ -0,0 +1,131 @@ +# WECG Meetings 2023, Public Notes, May 25 + + * Chair: Simeon Vincent + * Scribes: Rob Wu + +Time: 8 AM PDT = https://everytimezone.com/?t=646ea500,384 +Call-in details: [WebExtensions CG, 25th May 2023](https://www.w3.org/events/meetings/731a34ef-46f2-4ac6-8ae0-b30998883a29/20230525T080000) +Zoom issues? Ping @zombie (Tomislav Jovanovic) in [chat](https://github.com/w3c/webextensions/blob/main/CONTRIBUTING.md#joining-chat) + + +## Agenda: [discussion in #391](https://github.com/w3c/webextensions/issues/391), [github issues](https://github.com/w3c/webextensions/issues) + +The meeting will start at 3 minutes after the hour. + + * **Carry-over from previous meetings** + * [Issue 389](https://github.com/w3c/webextensions/issues/389): Proposal: Allow specifying frameId for devtools.inspectedWindow.eval api + * [Issue 385](https://github.com/w3c/webextensions/issues/385): WECG at TPAC 2023 + * **Other new issues** + * [Issue 394](https://github.com/w3c/webextensions/issues/394): [DNR] Add support for wildcards in initiatorDomains and excludedInitiatorDomains fields + * [Issue 396](https://github.com/w3c/webextensions/issues/396): Inconsistency: prerender documents get nonsensical frameId + * **Open discussion queue (add yourself at the bottom)** + * [anton] Bug in alarms API. + * [oliver] Appending User-Agent in DNR API + * **Check-in on ongoing issues** + * [Issue 387](https://github.com/w3c/webextensions/issues/387): Inconsistency: Permissions Inconsistency with New "SidePanel" + + +## Attendees (sign yourself in) + + 1. Simeon Vincent (Incremental Software) + 2. Rob Wu (Mozilla) + 3. Jason Waterman (Mozilla) + 4. Timothy Hatcher (Apple) + 5. Tomislav Jovanovic (Mozilla) + 6. David Johnson (Apple) + 7. Giorgio Maone (NoScript, Tor) + 8. Oliver Dunk (Google) + 9. Halil Emre Özen (Delivery Hero) + 10. Tim Heflin (Keeper) + 11. Maxim Topciu (AdGuard) + 12. Dmitriy Seregin (AdGuard) + 13. Cristina Yenyxe Gonzalez (eyeo) + 14. Dr. Humera Noor Minhas (eyeo) + 15. Mukul Purohit (Microsoft) + 16. Kiara Rose (Apple) + + +## Meeting notes + +[Issue 389](https://github.com/w3c/webextensions/issues/389): Proposal: Allow specifying frameId for devtools.inspectedWindow.eval api + + * [simeon] Title says it all. + * [rob] Sounds reasonable from Firefox's perspective. Chrome's DevTools framework is different from the extensions framework, so this may be non-trivial for them to implement. + * [timothy] Sounds reasonable. + * [oliver] Curious why it was frameUrl in the past, do you know why? It sounds reasonable though. + * [rob] I don't know that history. + +[Issue 385](https://github.com/w3c/webextensions/issues/385): WECG at TPAC 2023 + + * [simeon] TPAC on sep 11-13, see issue for times that we've tentatively signed up for. + * [timothy] I think we should talk more about making progress on writing the spec down and documenting/resolving inconsistencies. + * [oliver] Last year we did a bit of a retrospective. We should do something like that again. + * [simeon] If you have any other thoughts, please add them to the issue. + +[Issue 394](https://github.com/w3c/webextensions/issues/394): [DNR] Add support for wildcards in initiatorDomains and excludedInitiatorDomains fields + + * [maxim] Recently tried to move our experimental AdGuard extension to MV3 in Firefox, using declarativeNetRequest. + * [rob] FYI: Firefox recommends to use DNR where possible, but webRequest continues to be available in MV3. + * [rob] Wildcard support is not strictly required. The API does not limit the number of items in requestDomain nor initiatorDomains, and you can expand wildcard by explicitly listing all domains in the array. + * [maxim] Are you suggesting we explicitly list every top level domain? + * [rob] Yes, each one that you're interested in. + * [oliver] Are there use cases where you have a subdomain you want to match across hundreds of domains? + * [maxim] There are broad patterns we want to match against for Yandex and Google domains. + * [oliver] If you could list the domains you are trying to match, that would be useful. + * [sam] Wildcard shows right-handed wildcard, but there is also an implicit left-handed wildcard (subdomains are matched). Chrome has a left-handed wildcard, Safari doesn't. + * [timothy] We're going to change this domain matching to match Chrome's behavior. + * [rob] Firefox also matches Chrome's behavior: subdomain matching rather than exact domain matching. + * [rob] Without a compelling use case, I'm hesitant about this feature as extensions have other ways to accomplish the goal. Support for right-hand wildcards increases the requirements for the browser's implementation that reduces the potential for optimizations. + * [oliver] If there are examples where this really makes a difference, then we may reconsider. But given the arguments we're not in favor of support for this feature. + * [timothy] I agree. Sounds like a rare case. + * [simeon] Hypothetical: may run into limitations where listing all the matching domains is impractical. + * [timothy] Supporting this feature may also encourage requests for other APIs such as match patterns. + * [rob] Hesitant to encourage wildcard usage, as there are alternatives and the definition of a wildcard is not stable due to the addition and removal of TLDs. A mild concern is the use of wildcards when an explicit list of a few domains would have sufficed. + * [rob] Sounds like there is consensus on opposed, or neutral at best. + +[Issue 396](https://github.com/w3c/webextensions/issues/396): Inconsistency: prerender documents get nonsensical frameId + + * [simeon] Prerendered documents have a non-zero frameId despite the document being a main frame. + * [timothy] Safari doesn't run content scripts in prerendered documents until they become active. + * [anton] frameId is set to 0 as soon as the document becomes rendered. + * [tomislav] This is purposefully done in Chrome, I linked to a design doc from Chrome in the issue. I didn't see this publicly documented. + * [oliver] I need to take a closer look and fix the bug in the implementation or documentation. Let's close this issue and file a crbug. + * [timothy] May be useful to keep this open in the WECG to document it in the spec. + * [oliver] Is there interest among the other vendors to implement this? + * [tomislav] Maybe. And maybe also follow Safari's approach of delaying content script injection. + * [rob] Content scripts aren't the only way to observe prerendered content. WebNavigation and WebRequest also surface this, so we still need to decide on a sensible value for the frameId. + * [tomislav] Newest prerender proposal is in the WICG (incubator) group, unsure if Mozilla's web platform team plans about this: https://wicg.github.io/nav-speculation/prerendering.html + +[Issue 387](https://github.com/w3c/webextensions/issues/387): Inconsistency: Permissions Inconsistency with New "SidePanel" + + * [rob] Carry over from last week. I believe the ask for Google was whether they'd consider implementing sidebar_action for ease of cross-browser extension development. + * [oliver] Haven't had a chance to properly follow up. Firefox reps, do you have thoughts on how you'd like to proceed? + * [rob] Multiple browsers have implemented the Sidebar Action API, not just Firefox. E.g. Opera (a Chromium fork) also has the sidebar_action API. Google's sidepanel API doesn't offer capabilities that don't fit in sidebar_action. + * [tomislav] Overall easier for Chrome to align than for 3 other browsers to align. + * [timothy] Would prefer one design for this for consistency. Otherwise puts other browsers in the uncomfortable position of having to expose and support multiple APIs for compatibility. + * [tomislav] Also requires extensions to have to adapt to multiple implementations. + +[anton] Bug in alarms API. + + * [anton] Bug in alarms, not sure where to report. + * [alexei] uBlock Origin switched to alarms and then went back to setTimeout() because of [unintuitive behavior and/or browser bugs](https://github.com/uBlockOrigin/uBlock-issues/issues/2604#issuecomment-1523281685) in the alarms API. + * [rob] Would really like to discuss alarms in the group. There are a number of issues around how alarms behave around device sleep, background contexts suspending, extension update, etc. Please file an issue so we can discuss the desired vs currently implemented behaviors. + * [anton] I'll file an issue. + +[oliver] Appending User-Agent in DNR API + + * [oliver] I asked in the WECG chat, but didn't receive a response. We have a patch that would allow appending user agent header, but want to discuss before landing it. + * [david] We do allow appending to the User-Agent API. + * [timothy] No objection to this at the moment. We didn't have a separate list for allowing appending. + * [rob] set or append? + * [oliver] AFAIK we support setting the User-Agent header, but not “append”. + * [simeon] What does appending mean? + * [rob] There are a few headers that can also be repeated, which is canonically represented as concatenated with commas, but for user agent semicolons are used more often. + * [oliver] Sounds like there are no objections. I can file an issue and we can then put the appropriate headers on it. + * [timothy] Rob, are you suggesting that developers will have to decide whether or not to insert the semicolon? + * [rob] It's up to the implementation to decide how to append multiple values. For a single header, the common pattern is to use a semicolon to separate values. For example, the Cookie header. + * [simeon] Is there prior art for appending user agent strings where new user agents have been added to the string? + * [rob] Ancient plugins (Internet Explorer days), announcing their presence in the browser to the world. + * Action item: Oliver to file a new issue. + +The next meeting will be on [Thursday, June 8th, 8 AM PDT (3 PM UTC)](https://everytimezone.com/?t=64811a00,384). diff --git a/_minutes/README.md b/_minutes/README.md index 9beafe7d..a7f47ae3 100644 --- a/_minutes/README.md +++ b/_minutes/README.md @@ -10,22 +10,23 @@ After the end of each meeting, meeting notes are published here. ## Upcoming meetings -- 2023-05-25 at 8 AM PDT = https://everytimezone.com/?t=646ea500,384 - 2023-06-08 at 8 AM PDT = https://everytimezone.com/?t=64811a00,384 +- 2023-06-22 at 8 AM PDT = https://everytimezone.com/?t=64938f00,384 ## Past meetings +* 2023-05-25 ([minutes](2023-05-25-wecg.md)) * 2023-05-11 ([minutes](2023-05-11-wecg.md)) * 2023-04-27 ([minutes](2023-04-27-wecg.md)) * 2023-04-13 ([minutes](2023-04-13-wecg.md)) * 2023-03-30 ([minutes](2023-03-30-wecg.md)) -* 2023-03-16 ([minutes](2023-03-16-wecg.md))
All past meeting notes **2023** +* 2023-05-25 ([minutes](2023-05-25-wecg.md)) * 2023-05-11 ([minutes](2023-05-11-wecg.md)) * 2023-04-27 ([minutes](2023-04-27-wecg.md)) * 2023-04-13 ([minutes](2023-04-13-wecg.md))