-
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.
Merge pull request #444 from w3c/meeting-2023-08-31
Publish minutes of 2023-08-31 meeting
- Loading branch information
Showing
2 changed files
with
168 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,163 @@ | ||
| # WECG Meetings 2023, Public Notes, Aug 31 | ||
|
|
||
| * Chair: Timothy Hatcher | ||
| * Scribes: Rob Wu | ||
|
|
||
| Time: 8 AM PDT = https://everytimezone.com/?t=64efd800,384 | ||
| Call-in details: [WebExtensions CG, 31st August 2023](https://www.w3.org/events/meetings/51a7d2ff-e00d-462b-9071-73b93e78b053/20230831T080000/) | ||
| 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 208](https://github.com/w3c/webextensions/issues/208): Consider common API for push messages across browsers | ||
| * [Issue 362](https://github.com/w3c/webextensions/issues/362): Declarative cosmetic rules | ||
| * [Issue 344](https://github.com/w3c/webextensions/issues/344): Regular expressions in DNR API (regexFilter) | ||
| * **Other new issues** | ||
| * [Issue 438](https://github.com/w3c/webextensions/issues/438): sidePanel API: allow specifying a web site via url | ||
| * [Issue 439](https://github.com/w3c/webextensions/issues/439): Proposal: Add filter for DNR modifyHeaders | ||
| * [Issue 440](https://github.com/w3c/webextensions/issues/440): Proposal: add dictionary operations to DNR modifyHeaders | ||
| * [Issue 441](https://github.com/w3c/webextensions/issues/441): Is there any interest in creating extension-specific test harness like the WPT one? | ||
| * [Issue 443](https://github.com/w3c/webextensions/issues/443): Always on Top window | ||
| * [Issue 385](https://github.com/w3c/webextensions/issues/385): WECG at TPAC 2023 | ||
| * **Open discussion queue (add yourself at the bottom)** | ||
| * None | ||
| * **Check-in on ongoing issues** | ||
| * None | ||
|
|
||
|
|
||
| ## Attendees (sign yourself in) | ||
|
|
||
| 1. Rob Wu (Mozilla) | ||
| 2. Jason Waterman (Mozilla) | ||
| 3. Maxim Topciu (AdGuard) | ||
| 4. Dmitriy Seregin (AdGuard) | ||
| 5. Giorgio Maone (NoScript, Tor) | ||
| 6. Richard Worth (Capital One) | ||
| 7. Oliver Dunk (Google) | ||
| 8. Timothy Hatcher (Apple) | ||
| 9. Simeon Vincent (Unaffiliated) | ||
| 10. Matt Gibson (Bitwarden) | ||
| 11. Jackie Han (No affiliation) | ||
| 12. Carlos Jeurissen (Jeurissen Apps) | ||
| 13. Anton Bershanskyi (No affiliation) | ||
| 14. David Johnson (Apple) | ||
| 15. Patrick Kettner (Google) | ||
| 16. Steven McLintock (1Password) | ||
| 17. Benjamin Bruneau (1Password) | ||
| 18. Mukul Purohit (Microsoft) | ||
| 19. Kiara Rose (Apple) | ||
| 20. Tim Heflin (Keeper) | ||
| 21. Tomislav Jovanovic (Mozilla) | ||
| 22. Sam Macbeth (DuckDuckGo) | ||
|
|
||
|
|
||
| ## Meeting notes | ||
|
|
||
| [Issue 208](https://github.com/w3c/webextensions/issues/208): Consider common API for push messages across browsers | ||
|
|
||
| * [oliver] [Update in comment](https://github.com/w3c/webextensions/issues/208#issuecomment-1682416151) from Google side: webpush has [userVisibleOnly](https://developer.mozilla.org/en-US/docs/Web/API/PushSubscriptionOptions/userVisibleOnly) flag; Chrome is working on adding support for setting that flag to false. | ||
| * [simeon] I like this approach in general – leveraging existing web APIs and introducing small additional allowances for extensions. | ||
| * [timothy] Biggest reservation that I have is that our extension URLs change all the time, so how would we push to a URL that changes. | ||
| * [tomislav] We similarly have uniquely generated host names; in the identity API we use an artificial host name. | ||
| * [rob] The need for a public stable identifier tied to the extension has come up before, also in other proposals/issues in this group. | ||
| * [tomislav] I'll find more people to chat internally. | ||
| * [oliver] I'll link the CL. | ||
| * [rob] Is this available only to service workers, or also available to event pages? | ||
| * [timothy] SW only. | ||
| * [rob] If this is the API that we want extensions to use, then we should consider exposing it more broadly, to event pages. | ||
| * [simeon] Could an event page register a SW and handle the registration from there? | ||
| * [timothy] I think that a SW must be registered at a https:-scheme. | ||
| * [simeon] In Chrome the chrome-extension: scheme is treated as a secure origin, similar to special allowances for localhost. | ||
|
|
||
| [Issue 362](https://github.com/w3c/webextensions/issues/362): Declarative cosmetic rules | ||
|
|
||
| * [rob] We skipped this topic last time because Andrey wasn't here to speak to the topic. He's still not here. | ||
| * [dmitry] Last time we spoke about this, we decided to split off the scriptlets and cosmetic rules API. | ||
| * [simeon] Offline discussions have happened in this context; On the shape of the API and its proposed integration on DNR. Chrome has expressed some hesitation with that plan. Oliver, could you write a fuller comment? | ||
| * [oliver] I'll do that. | ||
| * [rob] I'll wait for Oliver's comment and add additional thoughts. | ||
|
|
||
| [Issue 344](https://github.com/w3c/webextensions/issues/344): Regular expressions in DNR API (regexFilter) | ||
|
|
||
| * [rob] Raised again recently by Andrey one month ago. I believe he wanted to check in on progress. The original goal of the issue was to identify a common set of regexFilter support across browsers. In the absence of a resolution there, Firefox now supports arbitrary regular expressions – whatever you can do in JS regexp you can do in a DNR regexp match pattern. | ||
| * [timothy] We have reached out internally to determine the feasibility of supporting the two features supported by Chrome, but no updates yet. | ||
| * [timothy] Negative look-ahead is probably not going to be supported by us. | ||
| * [oliver] That's not supported in Chrome either. | ||
| * [rob] Syntax supported by regexFilter is currently very broad, but explicitly documented to be subject to change with a reference to this WECG issue. | ||
| * [timothy] Is there a concern that developers will create rules that only work in Firefox? | ||
| * [rob] Not exactly. Relatively few extensions are using complex DNR rules at the moment. | ||
|
|
||
| [Issue 438](https://github.com/w3c/webextensions/issues/438): sidePanel API: allow specifying a web site via url | ||
|
|
||
| * [timothy] I'm not in favor of allowing arbitrary URLs. | ||
| * [simeon] Work-around for extensions is to use an iframe, but the issue with that is that web pages can try to prevent themselves from being embedded. This can be worked around, but doing so safely can be subtle. That raises the required technical skill and platform understanding to implement in an extension. | ||
| * [tomislav] This is an extension UI surface area, and we'd like to show indicators attributing the actual source to the user. If a web page is embedded there, it's no longer from an extension. | ||
| * [oliver] On the Chrome side I'd like to hear more about the use case for this. This looks like the desire to implement a mini browser in a sidebar. | ||
| * [rob] A concrete use case in Firefox is Side View (https://addons.mozilla.org/en-US/firefox/addon/side-view/), which can be used to load YouTube videos in the sidebar for example. | ||
| * [oliver] I'll run this by the team. More use cases would be helpful. Right now I'm leaning negative without use cases. | ||
|
|
||
| [Issue 439](https://github.com/w3c/webextensions/issues/439): Proposal: Add filter for DNR modifyHeaders | ||
|
|
||
| * [timothy] DNR feature to modify cookie or CSP header. | ||
| * [carlos] Thanks for the extended introduction. I think Rob has some thoughts about it. Rob? | ||
| * [rob] This proposal is a string-based operation. May work for simple extensions, but not for headers that are more complicated and structured. If the proposal addresses the needs of many developers, I'd be in favor of the capability. But if it doesn't cover much, I'd rather examine the use cases more closely and potentially find another solution. | ||
| * [timothy] I have similar concerns to Rob. In comparing string replacement with regexes: Regex-based operation may be more appealing to developers. | ||
| * [oliver] Similar concern to Rob that string matching can be complex. I'm also concerned about the performance impact of supporting more regexps. | ||
|
|
||
| [Issue 440](https://github.com/w3c/webextensions/issues/440): Proposal: add dictionary operations to DNR modifyHeaders | ||
|
|
||
| * [timothy] I'd be interested in seeing how this would work with CSP. | ||
| * [rob] I'd be interested in exploring ways to fulfill the needs of extensions without modifying CSP through DNR. As I mentioned in issue 169 at https://github.com/w3c/webextensions/issues/169#issuecomment-1701026141, header modifications are not enough. | ||
| * [timothy] We're looking at a different API because there are other ways CSP can be set and DNR only operates at the network level, correct? | ||
| * [rob] Yes. | ||
| * [carlos] It indeed would not cover all potential use cases. However it might cover a big chunk to be useful for the majority of extension developers and webRequest use cases. Not sure how many extensions use meta tags over headers. | ||
| * [rob] The way it's commonly used now is to completely strip CSP rather than have targeted relaxation. I'd much prefer to have targeted relaxation for specific purposes. | ||
| * [timothy] Cookies are similar. Attempting to modify cookies through the network layer doesn't necessarily capture everything either. | ||
|
|
||
| [Issue 441](https://github.com/w3c/webextensions/issues/441): Is there any interest in creating extension-specific test harness like the WPT one? | ||
|
|
||
| * [anton] I'm currently creating ad-hoc harnesses to test specific APIs. Would be | ||
| * [rob] Is this about testing extension APIs or extensions? | ||
| * [anton] Extension APIs. | ||
| * [timothy] So, testing specific APIs to explore differences between browsers? | ||
| * [anton] Yes. | ||
| * [tomislav] I am interested in creating something like that. | ||
| * [rob] Is this something we should talk about at TPAC? This is a subject that is valuable to all of us, but needs some discussion to converge towards an initial base before we can proceed with the implementation. | ||
| * [timothy] Yes, we should discuss at TPAC. | ||
| * [tomislav] Should talk with wpt people and once there is some agreement I'm interested in prototyping something in Firefox. | ||
| * [simeon] What's the difference between wpt tests and web pages? | ||
| * [tomislav] That's basically it. But there is a common framework between browsers and infrastructure to run and analyze results. | ||
| * [simeon] The reason I'm asking is, because the work so far, from my understanding of Anton's work is gathering the tests, not the framework itself. | ||
| * [rob] Anton, is that a correct description of your work? | ||
| * [anton] Yes. I have tests, but no framework. | ||
| * [tomislav] Sam from DuckDuckGo commented on the issue as well. | ||
| * [sam] We basically have an extension page that calls extension APIs and highlights inconsistencies between implementations. | ||
| * https://github.com/duckduckgo/mv3-compat-tests | ||
| * [tomislav] Would you be willing to collaborate tests to the suite? Is that compatible with your licensing and such? | ||
| * [sam] I think it's MIT. | ||
| * [simeon] I don't see a license in the repo. | ||
| * [sam] I'll fix that. | ||
| * [timothy] One question that comes to mind, Firefox has a browser.test namespace for testing that is close to what Firefox does, and Chrome has something similar. Perhaps we want to align here. | ||
| * [tomislav] The test namespace is only functional when run in tests. | ||
| * [timothy] Similarly in Safari, only available in debug builds. | ||
|
|
||
| [Issue 443](https://github.com/w3c/webextensions/issues/443): Always on Top window | ||
|
|
||
| * [timothy] I'm opposed to this unless the browser has affordances to allow the user to close / disable this, to counter abusive situations. | ||
| * [simeon] In the past I investigated why the chrome.app API supported this and the extension APIs don't. Mainly installs and use cases. Chrome is of course concerned about abuse cases and what's always on top. That said, I defer to the current Chrome team for their stance. | ||
| * [oliver] I don't have specific thoughts on this. The issue mentions Picture-in-Picture, would be nice to identify issues with that feature and improve if needed. | ||
| * [timothy] This is something we can add restrictions to. | ||
| * [rob] Some additional history, Chrome used to support the “panel” window type which had minimal browser chrome and appeared on top of everything. I think it was introduced for Hangouts or something but it has since been removed. I don't think extensions should be able to have an always-on-top window without the end user being able to opt out. | ||
| * [jackie] Chrome introduces a new API to create Picture-in-Picture windows, extensions can also use this API: https://developer.chrome.com/docs/web-platform/document-picture-in-picture/ | ||
|
|
||
| [Issue 385](https://github.com/w3c/webextensions/issues/385): WECG at TPAC 2023 | ||
|
|
||
| * [timothy] TPAC is in 2 weeks (11 and 12 september). We will still have our regular meeting on sep 14th. | ||
| * [simeon] On the issue itself we are maintaining a list of attendees. | ||
| * [rob] We should try to finalize the agenda as soon as possible. | ||
|
|
||
| The next meeting will be on [Thursday, September 14th, 8 AM PDT (3 PM UTC)](https://everytimezone.com/?t=65024d00,384). This is during the week of TPAC 2023 ([issue 385](https://github.com/w3c/webextensions/issues/385)), which includes sessions on September 11th and 12th. |
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