-
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 #634 from w3c/meeting-2024-06-06
Publish minutes of 2024-06-06 meeting
- Loading branch information
Showing
2 changed files
with
179 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,176 @@ | ||
| # WECG Meetings 2024, Public Notes, Jun 6 | ||
|
|
||
| * Chair: Simeon Vincent | ||
| * Scribes: Rob Wu | ||
|
|
||
| Time: 8 AM PDT = https://everytimezone.com/?t=6660fc00,384 | ||
| Call-in details: [WebExtensions CG, 6th June 2024](https://www.w3.org/events/meetings/a97adab8-e1ae-4a2b-85cf-e6b6d3d35f00/20240606T080000/) | ||
| Zoom issues? Ping @zombie (Tomislav Jovanovic) in [chat](https://github.com/w3c/webextensions/blob/main/CONTRIBUTING.md#joining-chat) | ||
|
|
||
|
|
||
| ## Agenda: [discussion in #621](https://github.com/w3c/webextensions/issues/621), [github issues](https://github.com/w3c/webextensions/issues) | ||
|
|
||
| The meeting will start at 3 minutes after the hour. | ||
|
|
||
| See [issue 531](https://github.com/w3c/webextensions/issues/531) for an explanation of this agenda format. | ||
|
|
||
| * **Announcements** (2 minutes) | ||
| * **Triage** (15 minutes) | ||
| * [Issue 624](https://github.com/w3c/webextensions/issues/624): Proposal: getLeafTarget() method ([@polywock](https://github.com/polywock)) | ||
| * [Issue 625](https://github.com/w3c/webextensions/issues/625): Spec Clarification: Autoplay Behavior on Extension Pages ([@hanguokai](https://github.com/hanguokai)) | ||
| * [Issue 626](https://github.com/w3c/webextensions/issues/626): Manifest v3 problems: ability to update the set-cookie header in response headers and also set dynamic header values ([@vish30](https://github.com/vish30)) | ||
| * [Issue 631](https://github.com/w3c/webextensions/issues/631): "side_panel":{} declaration should automatically grant sidePanel permission ([@tophf](https://github.com/tophf)) | ||
| * [Issue 632](https://github.com/w3c/webextensions/issues/632): Private tabs/windows handling in mobile form factors | ||
| * [Issue 633](https://github.com/w3c/webextensions/issues/633) Error / warning codes for extensions (manifest & API) | ||
| * **Timely issues** (10 minutes) | ||
| * _None currently. Double check at start of meeting._ | ||
| * **Check-in on existing issues** (20 minutes) | ||
| * [PR 598](https://github.com/w3c/webextensions/pull/598): Proposal: manifest key trial_tokens | ||
| * [PR 587](https://github.com/w3c/webextensions/pull/587): Proposal: downloads.getFileHash() | ||
| * [PR 586](https://github.com/w3c/webextensions/pull/586): Proposal: documentId in tabs.query() filter | ||
| * [PR 569](https://github.com/w3c/webextensions/pull/569): Add i18n-system-languages proposal | ||
| * New topics added during the meeting | ||
| * Open discussion: Proposal process timeline | ||
| * [Issue 160](https://github.com/w3c/webextensions/issues/160): Ensure consistency of action.openPopup API across browsers | ||
|
|
||
|
|
||
| ## Attendees (sign yourself in) | ||
|
|
||
| 1. Simeon Vincent (Mozilla) | ||
| 2. Rob Wu (Mozilla) | ||
| 3. Jarek Samic (1Password) | ||
| 4. Oliver Dunk (Google) | ||
| 5. Giorgio Maone (Tor, NoScript) | ||
| 6. Hilary Hacksel (1Password) | ||
| 7. David Johnson (Apple) | ||
| 8. Alan Byrne (Mozilla) | ||
| 9. Carlos Jeurissen (Jeurissen Apps) | ||
| 10. Mukul Purohit (Microsoft) | ||
| 11. Rémi Pujo (Dashlane) | ||
| 12. Steven McLintock (1Password) | ||
| 13. Tomislav Jovanovic (Mozilla) | ||
| 14. Solomon Kinard (Google) | ||
| 15. Tim Heflin (Keeper) | ||
|
|
||
|
|
||
| ## Meeting notes | ||
|
|
||
| [Issue 624](https://github.com/w3c/webextensions/issues/624): Proposal: getLeafTarget() method | ||
|
|
||
| * [simeon] Is polywock here? Does anyone have any context? | ||
| * [rob] Request is related to closed shadow DOM. | ||
| * [rob] Since nobody else has context here, I'll comment on the issue async. | ||
|
|
||
| [Issue 625](https://github.com/w3c/webextensions/issues/625): Spec Clarification: Autoplay Behavior on Extension Pages | ||
|
|
||
| * [simeon] According to jackie it is unclear how autoplay behaves on extension pages or subframes. My impression is that we generally follow the conventions from the web platform. | ||
| * [timothy] Historically we have granted autoplay capabilities to all extension pages in Safari (background, popup, etc.). This also includes programmatically triggering a play (which would ordinarily require a user gesture). | ||
| * [simeon] What about Firefox? | ||
| * [rob] I don't know for sure, but enabling extensions to play by default makes sense. Just for clarity, for content scripts we should want the web page's default behavior. | ||
| * [timothy] Yes. | ||
| * [simeon] How about Chrome? | ||
| * [oliver] I haven't looked at this before, but a quick look at the code and tests show that this is probably intended. | ||
| * [simeon] Would it make sense to write a spec text here? | ||
| * [rob] Let's use the spec clarification label on Github, when we get to writing the spec we can include this detail here. | ||
| * [rob] What about iframes in web content (web_accessible_resources)? Does it get the equal treatment as top-level extension documents? No need to answer now, but should be part of the description. | ||
|
|
||
| [Issue 626](https://github.com/w3c/webextensions/issues/626): Manifest v3 problems: ability to update the set-cookie header in response headers and also set dynamic header values | ||
|
|
||
| * [simeon] With DNR you cannot declaratively modify a response. | ||
| * [oliver] You can declaratively modify a response, including Set-Cookie. Perhaps they are affected by header modifications not showing up in devtools. | ||
| * [carlos] I believe that Chrome is going to add Set-Cookie modification based on regexp. Would it make sense to preset some variables like tabIds, e.g. in the regexp substitution? | ||
| * [rob] Even if technically feasible, I'm not sure if this is something we want to support. I also recall Chrome being concerned with exposing getFrameId to content scripts, and would imagine the hesitation to be even stronger with tabId exposed in headers/requests. | ||
| * [rob] For the specific use case, updateSessionRules + tabIds. | ||
| * [simeon] For this specific use case, the containers API would make more sense. | ||
| * [rob] The issue has two parts: the claim that set-cookie modification does not work (it does), and (2) some claim about DNR not being able to modify headers synchronously (this is by design, use webRequest otherwise). | ||
| * [oliver] Historically we haven't closed issues like this, but in the spirit of cleaning up issues, we should do. | ||
| * [simeon] Agreed. | ||
|
|
||
| [Issue 631](https://github.com/w3c/webextensions/issues/631): "side_panel":{} declaration should automatically grant sidePanel permission | ||
|
|
||
| * [simeon] In short, the request is for the “side_panel” manifest key to implicitly grant the “sidePanel” permission much like the “action” and “browser_action” keys do today. | ||
| * [timothy] Similarly for devtools_page. | ||
| * [oliver] I don't know about additional context. | ||
| * [simeon] Generally speaking, what is the preference from browser engineers, implicit or explicit permission requests? | ||
| * [timothy] Implicit permissions from the permission key makes sense. | ||
| * [tomislav] Issue that we would run into is if we ever want to make API permissions optional, ungrantable. Being more explicit in that case would make it more visible that a permission can be optional and can be re-granted again. | ||
| * [simeon] That rationale resonates with me. If in the long term we move towards permissions being optional. | ||
| * [simeon] What do we want to have as the standard behavior by design? | ||
| * [timothy] Depends on the permission and API behavior. Even if it is not a permission now, nothing precludes the browser from not showing the UI. In Safari for example, we do not grant the new tab page permission by default. | ||
| * [tomislav] It is good practice, but lacks discoverability from the extension. | ||
| * [timothy] I agree. I'll file a separate issue about the discoverability of the newtab page. | ||
| * [oliver] Two things we discussed; implicitly granting sidePanel permission from the manifest, which sounds reasonable. Secondly, dropping the sidePanel permission - I would not support that because some extensions may have the sidePanel permission without manifest key. | ||
| * [rob] If the manifest key is optional, then it would make sense to require the permission unconditionally for clarity on when a permission is required. | ||
| * [solomon] The issue calls out the action API as an example, but that is not really comparable since it doesn't have a permission. | ||
|
|
||
| [Issue 632](https://github.com/w3c/webextensions/issues/632): Private tabs/windows handling in mobile form factors | ||
|
|
||
| * [carlos] As a follow-up to the San Diego meetup; I described two approaches in the issue. (1) like Safari in iOS, pairing windows, groups of private tabs and non-private tabs. An issue is what happens when one of the windows is removed (2) Allowing mix of private and non-private windows. | ||
| * [rob] I'd reject option 2 because the API already assumes that “incognito” is a property of window, and a mix of private and non-private tabs in one window is incompatible with that design. | ||
| * [timothy] I prefer the private and non-private pair as implemented in Safari. | ||
| * [carlos] Having the window without a tab is not something that extensions are familiar with. | ||
| * [rob] What is the use case you're after private tabs? A specific solution for that without requiring a windows API is to introduce support for an “incognito” property which would open the tab in the default tab stack/window, or implicitly create a new window if it doesn't exist yet. | ||
| * [carlos] Not detailing use cases, only benefits and downsides | ||
| * [rob] Use cases are necessary to design the API. | ||
| * [simeon] Having an additional window spawned is odd | ||
| * [timothy] Definitely things we can do to improve the situation. Having a way to connect windows would be useful. Currently we don't support windows.remove, so the issue of closing a window doesn't exist. | ||
|
|
||
| [Issue 633](https://github.com/w3c/webextensions/issues/633) Error / warning codes for extensions (manifest & API) | ||
|
|
||
| * [solomon] This issue is inspired by my working on icon variants (dark mode). In Chrome we currently only expose an error string. | ||
| * [rob] This idea crossed my mind earlier today. E.g. in the downloads.download API an invalid filename may result in a failure to execute the requested download. Extensions often don't account for it, and even if it wanted to, the error message is implementation-specific. Having an error code would enable consistent error handling when error messages are inconsistent across browsers. | ||
| * [timothy] I agree. Error codes would help us to be consistent. | ||
| * [simeon] Should we require a manifest version bump for this? | ||
| * [rob] Not necessarily. We can make the change in a backwards-compatible way. The common interface between browsers is that the browser.runtime.lastError value (or Promise rejection) is an object with a string message. Firefox and Safari may have other properties (in fact the object is usually an Error instance), whereas in Chrome it is currently a plain object. | ||
| * [simeon] We could consider a unicode-like approach for error codes where we have a numeric space dedicated to common messages and a reserved numeric range for browser-specific errors. That could also provide a path to standardize common messages in the common error space. | ||
| * [timothy] I don't necessarily agree that we should standardize on the message format. As long as the code is the same, the message can be contextual. E.g. we don't allow persistent background pages in Safari on iOS, and include that in the error message. | ||
| * [rob] How would extensions receive that error? | ||
| * [timothy] Bad example because the extension does not load in that case. | ||
| * [solomon] I'll write a proposal. | ||
|
|
||
| [PR 598](https://github.com/w3c/webextensions/pull/598): Proposal: manifest key trial_tokens | ||
|
|
||
| * [simeon] Last call for feedback before merge. | ||
| * [rob] I saw your review approval. Is that on behalf of Mozilla or do I need to take an explicit look? | ||
| * [tomislav] I'll take a look. | ||
| * [rob] Thanks, I've reassigned the review request. | ||
|
|
||
| [PR 587](https://github.com/w3c/webextensions/pull/587): Proposal: downloads.getFileHash() | ||
|
|
||
| * [simeon] Missing Chrome approval. Any other actions required? | ||
| * [rob] This is a code contribution to Chrome, so Chrome approval is required here. | ||
| * [oliver] We need approval from privacy and security side, before we can approve this as a sponsoring browser. Waiting for me and Anton to collaborate on that. We just need a document to record the security and privacy side. | ||
| * [rob] Can this information be public? If there are any concerns that would be relevant to other browsers too. | ||
| * [oliver] As the sponsoring browser we'd like to get these approvals to make sure that we can implement this. | ||
|
|
||
| [PR 586](https://github.com/w3c/webextensions/pull/586): Proposal: documentId in tabs.query() filter | ||
|
|
||
| * [rob] Chromium is listed as the sponsoring browser, first step could for Chromium to get approval. | ||
| * [oliver] I was not involved here, I can take a look. | ||
| * [rob] We don't support documentId yet, but in general I am supportive to include it where it makes sense. | ||
|
|
||
| [PR 569](https://github.com/w3c/webextensions/pull/569): Add i18n-system-languages proposal | ||
|
|
||
| * [simeon] Apologies for the agenda confusion. | ||
| * [carlos] Is anything blocking merge? | ||
| * [oliver] Will follow up with Devlin. | ||
|
|
||
| Open discussion: Proposal process timeline | ||
|
|
||
| * [mukul] What timeline are we looking at when someone is sponsoring a proposal. | ||
| * [tomislav] I think that the context was “we are actively looking into implementing” the feature. 6-9 months would be reasonable. | ||
| * [oliver] Anything longer than a year would probably not match the definition of sponsoring. | ||
|
|
||
| [Issue 160](https://github.com/w3c/webextensions/issues/160): Ensure consistency of action.openPopup API across browsers | ||
|
|
||
| * [rob] Oliver commented on this at https://github.com/w3c/webextensions/issues/160#issuecomment-2145197651 | ||
| * [oliver] We have removed the user gesture requirement from action.openPopup in Chrome 127. If the action has been disabled, should you still be able to call action.openPopup? In Chrome we throw an error, in Safari it is possible, in Firefox nothing happens. | ||
| * [timothy] Throwing an error would make sense. | ||
| * [rob] Agreed. Any behavior is accidental. | ||
| * [oliver] A potential use case is to open the popup even if the UI is closed. Should the popup close if the button is closed? | ||
| * [timothy] We don't. | ||
| * [simeon] Could lead to weird UI state. | ||
| * [rob] From the API design perspective, the most sensible behavior is to throw if the popup is disabled, but keep the popup open if the button is disabled. The browser can decide to keep showing the button even if disabled (and hide the button to be consistent with the action.disable() state). | ||
| * [oliver] That is the behavior we implemented. | ||
|
|
||
| The next meeting will be on [Thursday, June 20th, 8 AM PDT (3 PM UTC)](https://everytimezone.com/?t=66737100,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