-
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 #371 from w3c/meeting-2023-03-30
Publish minutes of 2023-03-30 meeting
- Loading branch information
Showing
2 changed files
with
153 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,150 @@ | ||
| # WECG Meetings 2023, Public Notes, Mar 30 | ||
|
|
||
| * Chair: Tomislav Jovanovic (substituting for Simeon Vincent today) | ||
| * Scribes: Rob Wu | ||
|
|
||
| Time: 8 AM PDT = https://everytimezone.com/?t=6424d100,384 | ||
| Call-in details: [WebExtensions CG, 30th March 2022](https://www.w3.org/events/meetings/731a34ef-46f2-4ac6-8ae0-b30998883a29/20230330T080000) | ||
| Zoom issues? Ping @zombie (Tomislav Jovanovic) in [chat](https://github.com/w3c/webextensions/blob/main/CONTRIBUTING.md#joining-chat) | ||
|
|
||
|
|
||
| ## Agenda: [discussion in #364](https://github.com/w3c/webextensions/issues/364), [github issues](https://github.com/w3c/webextensions/issues) | ||
|
|
||
| The meeting will start at 3 minutes after the hour. | ||
|
|
||
| * **Carry-over from previous meetings** | ||
| * [Issue 317](https://github.com/w3c/webextensions/issues/317): registerProtocolHandler (protocol_handlers) in extensions | ||
| * Split off: [Issue 365](https://github.com/w3c/webextensions/issues/365): Support "protocol_handlers" in manifest | ||
| * [Issue 361](https://github.com/w3c/webextensions/issues/361): Add an API to integrate with the Credential Management Web API | ||
| * [Issue 352](https://github.com/w3c/webextensions/issues/352): SQLite via OPFS for Chrome Extension isn't quite supported | ||
| * [Issue 353](https://github.com/w3c/webextensions/issues/353): Support onEnabled event when the extension from disabled state to enabled state | ||
| * **Other new issues** | ||
| * [Issue 369](https://github.com/w3c/webextensions/issues/369): Inconsistency: declarativeNetRequest rules able to block background requests from other extensions | ||
| * [Issue 366](https://github.com/w3c/webextensions/issues/366): Inconsistency: Style in options_ui, browser_action, action | ||
| * [Issue 367](https://github.com/w3c/webextensions/issues/367): DNR & Proxy | ||
| * **Check in on PRs** | ||
| * [PR 370](https://github.com/w3c/webextensions/pull/370): Initial Firefox schemas, 2023Q1 | ||
| * **Check-in on ongoing issues** | ||
| * [Issue 279](https://github.com/w3c/webextensions/issues/279): User-Scripts API - where / how we can get an update on this? | ||
| * **Open discussion queue (add yourself at the bottom)** | ||
| * Open position on the Safari Extensions team (https://jobs.apple.com/en-us/details/200470467/software-engineer-safari-extensions?team=SFTWR) (Jessie) | ||
|
|
||
|
|
||
| ## Attendees (sign yourself in) | ||
|
|
||
| 1. Rob Wu (Mozilla) | ||
| 2. Jessie Berlin (Apple) | ||
| 3. Radoslaw Wasiuk (Dynatrace) | ||
| 4. Patrick Kettner (Google) | ||
| 5. Timothy Hatcher (Apple) | ||
| 6. Oliver Dunk (Google) | ||
| 7. Jason Waterman (Mozilla) | ||
| 8. Steven McLintock (1Password) | ||
| 9. Jackie Han (No affiliation) | ||
| 10. Tim Heflin (Keeper) | ||
| 11. Mukul Purohit (Microsoft) | ||
| 12. Tomislav Jovanovic (Mozilla) | ||
| 13. Maxim Topciu (AdGuard) | ||
| 14. Dmitriy Seregin (AdGuard) | ||
| 15. Anton Bershanskyi (Dark Reader) | ||
| 16. Simeon Vincent (Unaffiliated) | ||
| 17. Hal Massey (1Password) | ||
|
|
||
|
|
||
| ## Meeting notes | ||
|
|
||
| [Issue 317](https://github.com/w3c/webextensions/issues/317): registerProtocolHandler (protocol_handlers) in extensions | ||
|
|
||
| * [jackie] Previous discussion misinterpreted the issue as being about the manifest; I moved that to [issue 365](https://github.com/w3c/webextensions/issues/365): Support "protocol_handlers" in manifest. | ||
| * [jackie] Goal of 317 is to allow extensions to intercept clicks on custom protocols. | ||
| * [oliver] Differently from the usual protocol_handler feature is that the request here is to handle the protocol without navigating away. | ||
| * [timothy] In favor of manifest registering upfront without running background logic upfront. | ||
| * [oliver] Not about the registration, but more about where it is handled. | ||
| * [timothy] Less opinionated about that. | ||
| * [rob] So the request here is to handle protocol handlers without navigating away. What do we think of that? | ||
| * [tomislav] What are use cases that this feature could cover? | ||
| * [oliver] Jackie, do you have an example where it would be nice to not open a new tab? | ||
| * [jackie] magnet: link handler (BitTorrent). | ||
| * [tomislav] What's the use case not handled by opening an extension page? | ||
| * [jackie] Click on magnet: it should not navigate to another page. Currently developers use content script to handle magnet links as a workaround, but it needs host permissions. | ||
| * [rob] What are the positions of the browser vendors? | ||
| * [oliver] Being able to handle things in the background is interesting. | ||
| * [timothy] One concern that I have is links handled outside the browser; are they registered in the system? Concerned with routing all protocol handlers through the browser. | ||
| * [rob] We're neutral at best on this one, aren't we? | ||
|
|
||
| [Issue 361](https://github.com/w3c/webextensions/issues/361): Add an API to integrate with the Credential Management Web API | ||
|
|
||
| * [timothy] We have chatted about this internally (Apple/Safari), and are opposed to this. We'd prefer integration in password manager at the system level rather than the browser/extension level. | ||
| * [rob] Safari runs on only one OS, other browsers run across multiple OSs. One extension API would make it easier for password managers to implement the desired functionality without the current hacks/work-arounds. | ||
| * [timothy] We support the system password managers on macOS and iOS, but I get where you are coming from. | ||
| * [jessie] It's concerning here that extensions are overriding the credential managers. | ||
| * [tomislav] Offering credentials sounds good, but replacing the credential manager would be less appealing. | ||
| * [oliver] Haven't looked at the PR yet, but agreed with Tomislav's point. | ||
| * [simeon] For clarity, would Apple be opposed to having a browser extension password manager integrate with the browser's login experience? | ||
| * [jessie] Would need to go back to the relevant team to clarify their concerns and position. It's difficult to discuss in the abstract. A detailed proposal would be helpful. | ||
| * [simeon] When I was at Google, I had multiple conversations with the engineering team about this. For example, if the browser displays a list of credentials that the user can select from, the extension platform could provide a way for extensions to add entries to that list. I feel that there is a path here that makes all parties happy here. | ||
| * [tomislav] Safari extensions ship as apps, but extensions in other browsers don't. | ||
| * [timothy] Our platform could always provide a credential manager for the system, and Safari extensions could decide to not use the extension API even if it exists. | ||
| * [tomislav] Next steps here would be a more concrete proposal + credential manager engineers from the browsers to take a look at this. | ||
| * [oliver] What we'll end up with is likely far from close to the PR, so a better use of the time would be to continue discussing in the issue. | ||
|
|
||
| [Issue 352](https://github.com/w3c/webextensions/issues/352): SQLite via OPFS for Chrome Extension isn't quite supported | ||
|
|
||
| * [oliver] From the Chrome side: there is a work-around with the offscreen documents API. | ||
| * [oliver] There was a question before why it is not part of the service worker. The answer is because there is a concern over exposing sync blocking APIs to service workers. | ||
| * [tomislav] In Firefox event pages are supported, so that makes this a lesser issue. | ||
| * [timothy] Safari also supports event pages and introduced OPFS APIs to Safari 16.4. | ||
| * [tomislav] Firefox has also been working on OPFS APIs. | ||
| * [rob] Let's keep the issue open, and add the neutral flags from Firefox and Safari. | ||
| * [timothy] Makes sense to me. | ||
|
|
||
| [Issue 353](https://github.com/w3c/webextensions/issues/353): Support onEnabled event when the extension from disabled state to enabled state | ||
|
|
||
| * [rob] This topic was discussed before, why is this on the agenda again? | ||
| * [oliver] Update: I spoke to engineering on the Chrome side; concerned about including this in the onInstalled event. A new event would be preferred. There is also an issue about the event not firing when the extension updates while disabled. | ||
| * [tomislav] onStartup could be a fitting alternative. | ||
| * [timothy] Maybe a bug in Chrome; in Safari the onInstalled event is fired if the version changes. | ||
| * [timothy] At Safari we'd be fine with a new event or a reason on an existing event. | ||
| * [tomislav] For backward compatibility it would probably be better to have a new event. | ||
| * [oliver] I will follow up with engineering on this. | ||
|
|
||
| [Issue 369](https://github.com/w3c/webextensions/issues/369): Inconsistency: declarativeNetRequest rules able to block background requests from other extensions | ||
|
|
||
| * [rob] We discussed this before. We agreed that extensions should not be modifying requests from other extensions. | ||
| * [timothy] Last time we discussed this, the DNR does not affect requests from other extensions. | ||
| * [rob] I will add relevant links to issues to the bug and add supportive/implemented labels. | ||
|
|
||
| [Issue 366](https://github.com/w3c/webextensions/issues/366): Inconsistency: Style in options_ui, browser_action, action | ||
|
|
||
| * [timothy] We never supported the key in Safari. | ||
| * [oliver] I am not familiar with the key, but I can look into it. | ||
| * [tomislav] The feature allows extensions to inherit some default styles from the browser UI. I can imagine why it's removed, but it would be nice to see why. | ||
| * [timothy] When we decided to not implement it, we did not see many extensions using this. Most extensions have an opinionated stance on the appearance of the document and customize the CSS anyway. | ||
| * [anton] It would be convenient for extension devs if browsers provide a common set of styles/colors, but browsers are inconsistent. | ||
| * [timothy] “accentcolor” does not work in web pages out of fingerprinting concerns, but works in browser extensions. | ||
| * [rob] It is difficult for browsers to update the styles because that could break the appearance of extensions that rely on the “old” stylesheet. That's a reason to not spend more effort on expanding the browser_style / chrome_style features. | ||
|
|
||
| [Issue 367](https://github.com/w3c/webextensions/issues/367): DNR & Proxy | ||
|
|
||
| * [rob] Let's discuss this offline. webRequest.onAuthRequired is supported in MV3 despite the removal of blocking webRequest in Chrome. So I'd like to see the use case for a DNR API that cannot be covered by the webRequest API. | ||
|
|
||
| [PR 370](https://github.com/w3c/webextensions/pull/370): Initial Firefox schemas, 2023Q1 | ||
|
|
||
| * [tomislav] Initial PR with JSON schemas from Firefox; will need to figure out the license. Also, we have addons-linter project that consumes these schemas. There is also compatibility data available in the JSON of mdn/browser-compat-data, with method-level granularity. | ||
| * [tomislav] I will ask Rob and Simeon for review. | ||
| * [simeon] I'm also still working on Chrome's IDL. https://github.com/w3c/webextensions/pull/359. | ||
|
|
||
| [Issue 279](https://github.com/w3c/webextensions/issues/279): User-Scripts API - where / how we can get an update on this? | ||
|
|
||
| * [radoslaw] Can you please provide some information regarding the plan for User-Scripts implementation? It was declared that by March this API will be included in canary version of Chrome? We have an extension that records browser tests and we need functionality from the userScripts API. Some tests need custom logic that consists of custom JavaScript snippets. As the product owner I am concerned with the absence of the API and the impending MV2 deprecation in Chrome. | ||
| * [tomislav] I believe that Chrome has posted an update. | ||
| * [oliver] Back in December there was an update in the chromium-extensions list. Yesterday we posted a new update, there will be at least a 6 month heads-up before we start experimenting with MV2 deprecation in Chrome. | ||
| * December announcement: https://groups.google.com/a/chromium.org/g/chromium-extensions/c/zQ77HkGmK9E/m/1EwdKKZYAQAJ | ||
| * Yesterday's update: https://groups.google.com/a/chromium.org/g/chromium-extensions/c/zQ77HkGmK9E/m/HjaaCIG-BQAJ | ||
| * [oliver] On the userScripts API, the proposal has been merged into the WECG but the engineering work has not started yet. | ||
|
|
||
| Announcement by Apple: | ||
|
|
||
| * [jessie] Hiring for open position on the Safari Extensions team in San Diego (https://jobs.apple.com/en-us/details/200470467/software-engineer-safari-extensions?team=SFTWR) | ||
|
|
||
| The next meeting will be on [Thursday, April 13th, 8 AM PDT (3 PM UTC)](https://everytimezone.com/?t=64374600,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