-
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 #357 from w3c/meeting-2023-03-02
Publish minutes of 2023-03-02 meeting
- Loading branch information
Showing
2 changed files
with
140 additions
and
4 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,135 @@ | ||
| # WECG Meetings 2023, Public Notes, Mar 2 | ||
|
|
||
| * Chair: Simeon Vincent | ||
| * Scribes: Rob Wu | ||
|
|
||
| Time: 8 AM PST = https://everytimezone.com/?t=63ffe700,3c0 | ||
| Call-in details: [WebExtensions CG, 2nd March 2022](https://www.w3.org/events/meetings/731a34ef-46f2-4ac6-8ae0-b30998883a29/20230302T080000) | ||
| 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 349](https://github.com/w3c/webextensions/issues/349): Proposal: audible notifications (play a sound with a notification) | ||
| * **Other new issues** | ||
| * [Issue 356](https://github.com/w3c/webextensions/issues/356): Discuss: scripting.registerContentScripts() when there are no host permissions | ||
| * **Open discussion queue (add yourself at the bottom)** | ||
| * Any MV3 timeline updates? (Luke Selker) | ||
| * Activity-based SW lifecycle. (Luke Selker) | ||
| * **Check-in on ongoing issues** | ||
| * [Issue 344](https://github.com/w3c/webextensions/issues/344): Regular expressions in DNR API (regexFilter) | ||
| * [rob] [Issue 14](https://github.com/w3c/webextensions/issues/14): request: manifest error handling for unknown properties + [Issue 282](https://github.com/w3c/webextensions/issues/282): Proposal: declaring background scripts in a neutral way | ||
| * [Issue 332](https://github.com/w3c/webextensions/issues/332): Stable, documented and secure Auth API | ||
| * [Issue 13](https://github.com/w3c/webextensions/issues/13): Where do we start for a draft? | ||
|
|
||
|
|
||
| ## Attendees (sign yourself in) | ||
|
|
||
| 1. Simeon Vincent (independent) | ||
| 2. Rob Wu (Mozilla) | ||
| 3. Tomislav Jovanovic (Mozilla) | ||
| 4. David Johnson (Apple) | ||
| 5. Oliver Dunk (Google) | ||
| 6. Frederic Rivain (Dashlane) | ||
| 7. Benjamin Bruneau (1Password) | ||
| 8. Giorgio Maone (NoScript, Tor) | ||
| 9. Luke Selker (Dashlane) | ||
| 10. Mukul Purohit (Microsoft) | ||
| 11. Dmitriy Seregin (AdGuard) | ||
| 12. Maxim Topciu (AdGuard) | ||
| 13. Steven McLintock (1Password) | ||
|
|
||
|
|
||
| ## Meeting notes | ||
|
|
||
| [Issue 349](https://github.com/w3c/webextensions/issues/349): Proposal: audible notifications (play a sound with a notification) | ||
|
|
||
| * [simeon] Currently not possible to play audio when notification is played. This is also a limitation on the web platform. Current work-around on the platform is to play an audio simultaneously with the notification. Challenge with Service Worker is that it is not possible to play audio together with the notification, though it would be possible with an Offscreen document. | ||
| * [rob] Firefox's notifications are based heavily on what the host OS provides. I'm not terribly comfortable exposing audio playback as a required part of this API. At most advisory. | ||
| * [tomislav] This is not just ergonomics. Like Rob said, most platforms try to use the OS native features that includes accounting for muting. This may be a suggestion for the browser to play audio. | ||
| * [timothy] We wouldn't want extensions to do this themselves. While we don't support the notifications API yet, I'd be in favor of a declarative way. The audio part should be advisory. | ||
| * [simeon] By not providing this capability, extensions would take the forced route. | ||
| * [tomislav] Are you concerned with this feature being advisory? | ||
| * [simeon] Having this being advisory is better than not having the option at all. | ||
| * [rob] The issue claims that the feature is common and highly demanded. Does anyone have data that backs this claim? | ||
| * [timothy] I don't. Some websites do that, but on the webpage. If we translate that to extensions, then it may be desirable for some to associate the audio with their brand. | ||
| * [simeon] I don't think that this is a heavily desired feature, but probably desired. | ||
| * [rob] Positions here? Looks like at least Firefox and Safari are neutral, provided that the flag is advisory. | ||
| * [oliver] Chrome: Neutral too, agree with the arguments here. | ||
|
|
||
| [Issue 356](https://github.com/w3c/webextensions/issues/356): Discuss: scripting.registerContentScripts() when there are no host permissions | ||
|
|
||
| * [simeon] Summarizes issue; Main issue is that one can register scripts without having permissions. | ||
| * [tomislav] Not opposed to the proposal, but I don't think it's necessary. In Firefox MV3 and Safari, users can opt in to run scripts on click. Not just these from the scripting API, but also the content_scripts in manifest.json. I wouldn't tie content script registration with automatically granting host permissions. I believe that Safari may sometimes automatically trigger the optional permission prompt when it makes sense in the UX. | ||
| * [timothy] Safari does currently support registerContentScripts in the Tech Preview and Safari 16.4 Beta. We treat these scripts similarly to these in the manifest. When the user visits a tab, and a script was registered for example.com, then a permission prompt is shown when the user clicks on the extension toolbar item. If the user has not interacted with the extension yet, an attention-drawing badge is shown. | ||
| * [simeon] From my POV, the primary issue is the difference between the manifest and dynamically registered scripts. It's a mental model mismatch. Perhaps browsers could help developers by warning if a match pattern has a host that the extension doesn't have host permission for. | ||
| * [rob] Extensions should already account for permissions to be missing. Even if granted initially, the user may revoke the permission later. Along with that, even if host permissions are fully granted, there may still be websites that extensions cannot access (e.g. Chrome Web Store in Chrome, Firefox add-ons gallery in Firefox, etc). | ||
| * [oliver] matches is an array. The extension may have been granted partial permissions. Raising an error here is not obviously the desired behavior. | ||
| * [timothy] In Safari host permissions may auto-expire after a day if the user chooses that. In Safari we don't treat match permissions from content scripts different from host_permissions in the manifest file. | ||
| * [tomislav] Same for Firefox in Manifest V3. Host permissions from content script match patterns in the manifest are implied. | ||
| * [simeon] If I have an extension with a content scripts for <all_urls> and the cookies permission, would the extension get access to cookies on all URLs? | ||
| * [tomislav] In Firefox in MV3, yes. An extension could also have run a content script and used document.cookie to extract cookies. | ||
| * [timothy] Same for Safari. We will not do this for <all_urls> as it's a special case, but we will for specific hosts. | ||
| * [timothy] If extension authors really want to have this, then they can use permissions.request() along with their own desirable user interface. | ||
| * [rob] Looks like we're all opposed to the proposal. The flag does not satisfy the expectations of developers, and there is already an alternative to have the requested functionality. | ||
|
|
||
| Any MV3 timeline updates? (Luke Selker) | ||
|
|
||
| * [luke] Any updates on the MV2 deprecation? | ||
| * [oliver] Our last update is in December, with an update in March. So soon. | ||
| * [timothy] We have no plans to deprecate MV2. | ||
| * [rob] Firefox does currently not have any MV2 deprecation plans. If we do evaluate whether and how to approach MV2, there'd be at least 1 year notice. | ||
|
|
||
| Activity-based SW lifecycle. (Luke Selker) | ||
|
|
||
| * [luke] Chrome's known issue item tracking SW lifecycle has been closed, but that was only regarding the 5 minute limit. Not clear if there's any additional documentation | ||
| * [oliver] Any extension event will extend the SW's lifetime https://developer.chrome.com/blog/longer-esw-lifetimes/ | ||
| * [timothy] That's what Safari does today as well. Any event being dispatched to a SW will extend its lifetime. After 30 seconds of inactivity it will be terminated, I believe that's the same behavior as Chrome. | ||
| * [tomislav] In Firefox the behavior is as just described for Safari. | ||
| * [rob] FYI: Chrome's bug to track lifetime extensions: https://bugs.chromium.org/p/chromium/issues/detail?id=1418780 | ||
| * [luke] The events that do extend the lifetime; you mentioned there's a 30 second window. | ||
|
|
||
| [Issue 344](https://github.com/w3c/webextensions/issues/344): Regular expressions in DNR API (regexFilter) | ||
|
|
||
| * [simeon] Any updates here? | ||
| * [simeon] Chrome's regexFilter is backed by RE2 and it is unlikely for another engine to be adopted. | ||
| * [oliver] I have to investigate whether there may be potential “easy-wins” to expand coverage for desired regular expressions in Chrome. | ||
|
|
||
| [Issue 14](https://github.com/w3c/webextensions/issues/14): request: manifest error handling for unknown properties | ||
|
|
||
| * [rob] + [Issue 282](https://github.com/w3c/webextensions/issues/282): Proposal: declaring background scripts in a neutral way | ||
| * [rob] Revisiting for visibility. Chrome does not support the “scripts” property in Manifest V3. Other browsers will use this for event pages in Manifest V3. Chrome is currently refusing to load the extension if background.scripts is present, but in the interest of enabling extensions authors to reuse the same extension and manifest file across multiple browsers, there is consensus to treat the presence of unsupported background keys as a warning rather than a hard error. | ||
| * [rob] Intent from all browser vendors is to not throw hard errors unless absolutely necessary. There's also some confusion between “error” and “warning” here. In this context “error” means the browser refuses to load and “warning” means something logged to the console after the extension has loaded. | ||
| * [oliver] Agreed with everything that Rob just said. | ||
| * [timothy] Same. I think that we need to be more permissive with missing properties. E.g. recent issue is when “ios” key is present in the “commands” dictionary, which prevents developers from using a single manifest file. | ||
| * [oliver] I'm supportive of ignoring/warning on “ios” instead of refusing to load. | ||
| * https://bugs.chromium.org/p/chromium/issues/detail?id=1418342 | ||
| * [simeon] Note that extensions can use enums in the JS APIs to detect what the supported values are for a given browser. Is there a way for extension devs to detect an error that occurs during manifest parse? | ||
| * [rob] Manifest errors or runtime errors? Runtime errors can already be detected. For manifest, getManifest() could be used. | ||
| * [rob] In Firefox, runtime.getManifest() returns the normalized manifest (i.e. the browser's interpretation of the manifest) | ||
| * [timothy] We return whatever was in the manifest.json file. We should track this as an inconsistency. | ||
| * [timothy] In the specific case of commands + ios, there is no enum to tell what platforms are supported. | ||
|
|
||
| [Issue 332](https://github.com/w3c/webextensions/issues/332): Stable, documented and secure Auth API | ||
|
|
||
| * [simeon] Revisiting as this was raised and immediately tabled in a previous meeting. In short, not all auth services are compatible with service worker based extensions. `browser.identity` isn't well documented. To my mind, the base question is should the platform handle authentication. | ||
| * [timothy] Safari does not support as of now | ||
| * [rob] The way Firefox handles the Identity API: It is not associated with any particular OAuth provider (like Chrome). It accepts a URL to initiate the OAuth flow and opens a popup + tracks redirect to ultimately extract the received token (https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/WebExtensions/API/identity/launchWebAuthFlow). | ||
| * [simeon] There's a desire for a generic, non-Google owned identity provider support in Chrome. Timothy, do you have any feelings one way or the other about having the extension platform take over some of the OAuth flow? | ||
| * [timothy] That seems like a good idea, we have a native API for this and I would be in support of this idea. | ||
| * [rob] The generic API we're considering is already launchWebAuthFlow, but comments in issue 332 suggest that there are some limitations or implementation bugs that limit the usefulness in some cases. | ||
| * [rob] So it looks like we are at least neutral (potentially supportive) towards the capability, but have no idea how the API should look like | ||
| * [simeon] Yes, next step would be for somebody to investigate the details and propose concrete next steps. | ||
|
|
||
| [Issue 13](https://github.com/w3c/webextensions/issues/13): Where do we start for a draft? | ||
|
|
||
| * [simeon] I'm currently preparing a PR to add Chrome IDL files to the directory. | ||
| * [rob] Only the IDL or also its JSON files? | ||
| * [simeon] IDL and JSON. | ||
| * [tomislav] We (Firefox) will add JSON schemas. | ||
|
|
||
| The next meeting will be on [Thursday, March 16th, 8 AM PDT (3 PM UTC)](https://everytimezone.com/?t=64125c00,384). | ||
| Warning: Clock changes before the next meeting: PST changes to PDT. Double-check whether the meeting is held at the usual time in your region. |
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