-
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 #465 from w3c/meeting-2023-10-12
Publish minutes of 2023-10-12 meeting
- Loading branch information
Showing
2 changed files
with
143 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,140 @@ | ||
| # WECG Meetings 2023, Public Notes, Oct 12 | ||
|
|
||
| * Chair: Timothy Hatcher | ||
| * Scribes: Rob Wu | ||
|
|
||
| Time: 8 AM PDT = https://everytimezone.com/?t=65273700,384 | ||
| Call-in details: [WebExtensions CG, 12th October 2023](https://www.w3.org/events/meetings/1cc4723f-c539-4c9b-94d2-912bcc2598c9/20231012T080000/) | ||
| 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 456](https://github.com/w3c/webextensions/issues/456): Proposal: Provide reporting event for browser's slow extension warnings | ||
| * [Issue 457](https://github.com/w3c/webextensions/issues/457): Proposal for runtime.onConnectNative Event | ||
| * [Issue 316](https://github.com/w3c/webextensions/issues/316): tabs.getCurrent() returns undefined when being called from the popup (further tabs.getCurrent() discussion) | ||
| * [Issue 460](https://github.com/w3c/webextensions/issues/460): Proposal: declarativeNetRequest: matching based on response headers | ||
| * [Issue 461](https://github.com/w3c/webextensions/issues/461): Proposal: webRequest worklets | ||
| * [Issue 462](https://github.com/w3c/webextensions/issues/462): Proposal: Add Support for Dynamic SVG Icons in browser.action.setIcon() | ||
| * **Other new issues** | ||
| * None | ||
| * **Open discussion queue (add yourself at the bottom)** | ||
| * None | ||
| * **Check-in on ongoing issues** | ||
| * None | ||
|
|
||
|
|
||
| ## Attendees (sign yourself in) | ||
|
|
||
| 1. Steven McLintock (1Password) | ||
| 2. Timothy Hatcher (Apple) | ||
| 3. Giorgio Maone (Tor, NoScript) | ||
| 4. Rob Wu (Mozilla) | ||
| 5. Tomislav Jovanovic (Mozilla) | ||
| 6. Richard Worth (Capital One) | ||
| 7. Kiara Rose (Apple | ||
| 8. Oliver Dunk (Google) | ||
| 9. Cristina Yenyxe Gonzalez (eyeo) | ||
| 10. Dmitriy Seregin (AdGuard) | ||
| 11. Carlos Jeurissen (Jeurissen Apps) | ||
| 12. David Johnson (Apple) | ||
| 13. Maxim Topciu (AdGuard) | ||
| 14. Tim Heflin (Keeper) | ||
| 15. Mukul Purohit (Microsoft) | ||
| 16. Sam Macbeth (DuckDuckGo) | ||
|
|
||
|
|
||
| ## Meeting notes | ||
|
|
||
| [Issue 456](https://github.com/w3c/webextensions/issues/456): Proposal: Provide reporting event for browser's slow extension warnings | ||
|
|
||
| * [timothy] Firefox and Chrome have similar warnings; Safari doesn't. The idea is to report an event to extensions to enable them to respond to this. I have commented on this issue, that I don't think that this would be feasible. | ||
| * [tomislav] On Firefox's side I don't know the latest details; this often happens in a content script. We'd be open to implementing this. | ||
| * [rob] Is this content-script-only or are background pages in scope? | ||
| * [sam] The conditions for triggering this are browser-specific; in Firefox it's content scripts, in Chrome it's background scripts. A notification would enable extensions to deal with this. We had a bug and an event like this would have helped with narrowing down the issue. | ||
| * [timothy] So knowing what page or URL this is happening on would have helped with narrowing down the issue. | ||
| * [sam] Yes, in this case a content script was hitting the issue on a specific page. | ||
| * [tomislav] I'm not sure if we'd report the URL remotely where this happens due to privacy concerns. Reporting to an event would be more acceptable. | ||
| * [oliver] webRequest.handlerBehaviorChanged too frequently would trigger the notification. I don't see much value in exposing this in an event without also adding more cases where we can detect performance issues. | ||
| * [timothy] I agree with the privacy concerns. | ||
| * [sam] | ||
| * [tomislav] Seems useful, we can at least create a Bugzilla issue for this on Firefox's side. | ||
| * [rob] The “slow page warning” is implementation-specific. I wouldn't mind filing a bug for this, but I'd like to see use cases and cross-browser alignment before pursuing this idea. | ||
| * [cristina] Getting real world notifications helps with debugging for us. | ||
| * [timothy] But having the reporting go through the browser and then a remote destination would not include the URL. Should we fire an event to the extensions so that they can log if needed, while keeping the privacy in mind? | ||
| * [tomislav] I expect something like that, yes. | ||
| * [sam] In theory the event can already be implemented in user land, so I don't think that this would be a significant privacy issue. | ||
| * [timothy] The concern here was automatic collection and forwarding remotely. | ||
|
|
||
| [Issue 457](https://github.com/w3c/webextensions/issues/457): Proposal for runtime.onConnectNative Event | ||
|
|
||
| * [timothy] Looking for a way to allow external apps to invoke native messaging in the browser. | ||
| * [oliver] Command-line parameter to trigger the native app. | ||
| * [rob] I've seen Chrome's relevant code before, Oliver's description is correct here. | ||
| * [rob] It would be useful if the requirements/expectations from Safari's end are documented in the issue. In particular, what happens if Safari isn't around? | ||
|
|
||
| [Issue 316](https://github.com/w3c/webextensions/issues/316): tabs.getCurrent() returns undefined when being called from the popup (further tabs.getCurrent() discussion) | ||
|
|
||
| * [timothy] tabs.getCurrent() documented to return undefined if not in a tab context. There is discussion to expand this to the extension popup. | ||
| * [carlos] I added this discussion topic; In a browser extension I am using tabs.getCurrent() to the tabId to limit webRequest filters to the current window. Although Safari hasn't implemented the webRequest API, there may be similar requests where this logic would be useful. I'd suggest a new method. | ||
| * [timothy] tabId is more useful outside of tabs, e.g. in popups. I'd be supportive. | ||
| * [carlos] Similar API in devtools API - devtools.inspectedWindow.tabId. | ||
| * [rob] let's not conflate the APIs (their implementations are independent). I'm curious though - why a new method instead of tabs.getCurrent()? | ||
| * [carlos] Then you can know if you're in a popup. And tabs.getCurrent() is already defined to return undefined in a non-tab context. | ||
| * [timothy] tabs.getCurrent() is currently not useful outside of a tab context. And not available to a content script. | ||
| * [rob] Let's consider content scripts out of scope, and focus on privileged extension contexts only. | ||
| * [timothy] Agreed. | ||
| * [rob] If backwards compatibility with the return value is a concern, we can introduce a new parameter to the tabs.getCurrent() method. | ||
| * [tomislav] “current” can already be retrieved with tabs.query. In the context of popups, we'd like to retrieve the initial tab, that was open at the time of opening the popup. | ||
| * [kiara] I don't mind the name. | ||
| * [rob] In that case I would suggest a new method to be added to the action API. | ||
| * [oliver] Next question is sync vs async method. | ||
| * [tomislav] I don't disagree, but note that tabId isn't useful without async API calls, so I would not limit it to be synchronous. | ||
| * [rob] Extensions should be prepared to deal with the tab being gone. This is always a possibility. | ||
| * [oliver] During TPAC we discussed scenarios where the popup continues to be around while the tab is closed. | ||
| * [tomislav] In Firefox yes. | ||
| * [timothy] In Safari on Mac, it is possible to cmd-click a background window to cause the popover to appear in a background window while there is another active foreground window/tab. | ||
| * [rob] We're going in too much detail here - let's focus. At a high level, do we want this? | ||
| * [oliver] I think it makes sense to find a solution, and it does not need to be now. | ||
|
|
||
| [Issue 460](https://github.com/w3c/webextensions/issues/460): Proposal: declarativeNetRequest: matching based on response headers | ||
|
|
||
| * [oliver] DNR use case: Content-type:application/pdf can redirect to PDF. | ||
| * [timothy] How do you do the matching if something doesn't exist? | ||
| * [oliver] I think that was in the first iteration of the proposal. I have to check if it is still there. | ||
| * [rob] This use case is basically my extension's (PDF Viewer). I saw the comment on crbug, and am going to respond after reviewing the proposal more closely. | ||
| * [oliver] There were multiple use cases, but the PDF viewer extension was a major one. | ||
| * [timothy] We've seen similar use cases. | ||
| * [timothy] Presumably upgrade scheme wouldn't be supported? | ||
| * [timothy] regex - case-insensitive? | ||
| * [timothy] Overall - supportive. | ||
|
|
||
| [Issue 461](https://github.com/w3c/webextensions/issues/461): Proposal: webRequest worklets | ||
|
|
||
| * [timothy] Introducing small JS snippets instead of webRequest, basically. In my opinion, goes against the direction of DNR - a declarative API. Safari would probably not support it. | ||
| * [oliver] In a long-term vision, this sounds interesting. Some limited syntax could be interesting. | ||
| * [rob] I've considered this idea in the past, but dropped it. Any dynamic execution with any form of state persistence or leaking (e.g. redirects/header modifications) can result in data exfiltration. At that point there is little benefit over supporting something like webRequest in the background context. | ||
| * [oliver] Maybe performance benefits. | ||
| * [timothy] I'd be opposed to a language other than JavaScript. | ||
| * [tomislav] Maybe WebAssembly. | ||
| * [oliver] Something interesting to think about, but definitely not something that we'd work on anytime soon. | ||
|
|
||
| [Issue 462](https://github.com/w3c/webextensions/issues/462): Proposal: Add Support for Dynamic SVG Icons in browser.action.setIcon() | ||
|
|
||
| * [timothy] We'd like extensions to use vectorized icons. | ||
| * [rob] The API already supports size-to-URL mappings. Why is that not sufficient? | ||
| * [timothy] The image data case is useful for dynamically drawn icons. My goal is to support dynamically generated SVGs. | ||
| * [rob] Your assumption of SVGs scaling automatically is not automatically true in every implementation. E.g. I know that Chrome rasterizes the SVG icon with Skia. | ||
| * [timothy] Different ideas: data:-URL, passing SVG element. | ||
| * [rob] SVG is DOM, Chrome would probably be opposed since it's not supported in a service worker. | ||
| * [rob] The API already supports ImageData, why not use it? Aha - because it's a raster image and you want to support vector images. | ||
| * [timothy] Exactly. | ||
| * [rob] If we set the implementation details aside, the request here is to support vector images in the action API, and I am supportive of that. | ||
| * [tomislav] I prefer alternatives over data:-URLs. E.g. fragments in SVG. | ||
| * [oliver] Generally supportive of SVGs in the action API. | ||
| * [mukul] We'd also be supportive, from Microsoft's side. | ||
|
|
||
| The next meeting will be on [Thursday, October 26th, 8 AM PDT (3 PM UTC)](https://everytimezone.com/?t=6539ac00,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