-
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 #321 from w3c/meeting-2022-11-10
Publish minutes of 2022-11-10 meeting
- Loading branch information
Showing
2 changed files
with
185 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,182 @@ | ||
| # WECG Meetings 2022, Public Notes, Nov 10 | ||
|
|
||
| * Chair: Simeon Vincent | ||
| * Scribes: Rob Wu | ||
|
|
||
| Time: 8 AM PST = https://everytimezone.com/?t=636c3f00,3c0 | ||
| Call-in details: [WebExtensions CG, 10th November 2022](https://www.w3.org/events/meetings/d7bbce8f-549f-46ea-b440-ea6902f8707c/20221110T080000) | ||
| Zoom issues? Ping @zombie (Tomislav Jovanovic) [in chat](https://github.com/w3c/webextensions/blob/main/CONTRIBUTING.md#joining-chat) | ||
|
|
||
|
|
||
| ## Agenda: [discussion in #314](https://github.com/w3c/webextensions/issues/314), [github issues](https://github.com/w3c/webextensions/issues) | ||
|
|
||
| The meeting will start at 3 minutes after the hour. | ||
|
|
||
| * **Housekeeping** | ||
| * Today's agenda & format | ||
| * [Issue 244](https://github.com/w3c/webextensions/issues/244#issuecomment-1291174495): New labels: "breaking change", "topic: localization", "topic: action" | ||
| * **Pull requests** | ||
| * [PR 291](https://github.com/w3c/webextensions/pull/291): Document How we work | ||
| * **Quick check-ins** | ||
| * (follow-up from TPAC) Check in on status of gathering IDL/JSON for spec work | ||
| * [Issue 12](https://github.com/w3c/webextensions/issues/12): request: allow to retrieve a frameID from an <iframe> element | ||
| * Check-in on support for runtime.getFrameId() | ||
| * [Issue 188](https://github.com/w3c/webextensions/issues/188): Inconsistency: Permissions "menus" | ||
| * Check-in on support for replacing contextMenus with menus and (2) changing the API signature of menus.create / contextMenus.create | ||
| * [Issue 282](https://github.com/w3c/webextensions/issues/282): Proposal: declaring background scripts in a neutral way | ||
| * [Issue 160](https://github.com/w3c/webextensions/issues/160): Ensure consistency of action.openPopup API across browsers | ||
| * **Follow up from last meeting** | ||
| * [Issue 294](https://github.com/w3c/webextensions/issues/294): Proposal: one-time message passing addressed to a specific documentId or contextId | ||
| * [Issue 300](https://github.com/w3c/webextensions/issues/300): Proposal: Improve the browser.commands API | ||
| * [Issue 308](https://github.com/w3c/webextensions/issues/308): New api: shortcut changed event | ||
| * [Issue 309](https://github.com/w3c/webextensions/issues/309): Unify the format of Command.shortcut or add a new Command.shortcutKeys property | ||
| * [Issue 310](https://github.com/w3c/webextensions/issues/310): New API: Open Shortcut Setting | ||
| * **New Issues** | ||
| * [Issue 304](https://github.com/w3c/webextensions/issues/304): Automatically grant https: host_permissions with http: | ||
| * Not covered due to the lack of time. For the original list, see https://github.com/w3c/webextensions/issues/314 | ||
| * **Ongoing issues in need for discussion** | ||
| * [Issue 279](https://github.com/w3c/webextensions/issues/279): User scripts in MV3 | ||
| * Not covered due to the lack of time. For the original list, see https://github.com/w3c/webextensions/issues/314 | ||
|
|
||
|
|
||
| ## Attendees (sign yourself in) | ||
|
|
||
| 1. Simeon Vincent (Google) | ||
| 2. David Johnson (Apple) | ||
| 3. Rob Wu (Mozilla) | ||
| 4. Giorgio Maone (NoScript, Tor Project) | ||
| 5. Jack Works (Sujitech) | ||
| 6. Tim Heflin (Keeper) | ||
| 7. Sam Macbeth (DuckDuckGo) | ||
| 8. Oliver Dunk (1Password) | ||
| 9. Benjamin Bruneau (1Password) | ||
| 10. Juha-Matti Santala (Mozilla) | ||
| 11. Todd Schiller (PixieBrix) | ||
| 12. Tomislav Jovanovic (Mozilla) | ||
| 13. Kiara Rose (Apple) | ||
| 14. Timothy Hatcher (Apple) | ||
| 15. Andrey Meshkov (AdGuard) | ||
| 16. Dmitriy Seregin (AdGuard) | ||
| 17. Lucas Selker (Dashlane) | ||
| 18. Emilia Paz (Google) | ||
| 19. Steven McLintock (1Password) | ||
| 20. Carlos Jeurissen (Jeurissen Apps) | ||
| 21. Tyler Carson (Keeper) | ||
| 22. Maxim Topciu (AdGuard) | ||
| 23. Mukul Purohit (Microsoft) | ||
|
|
||
|
|
||
| ## Meeting notes | ||
|
|
||
| Introduction | ||
|
|
||
| * [simeon] Today has a different format than usual. Carlos helped with creating the agenda today ([issue 314](https://github.com/w3c/webextensions/issues/314)), instead of our usual Newest issue-first approach. | ||
| * [carlos] It is a long list, it is not a goal to tackle all of them. Prefer to complete topics fully before moving to the next one. | ||
| * [rob] As part of the meeting note publication process, I usually link all discussed topics to the meeting notes PR on Github, which automatically shows up on the Github issues. Given the many topics here, I will delete the ones that have not been discussed to avoid the incorrect impression of an issue having been covered. | ||
| * [simeon] In the future we may not have a list of “New issues”. | ||
| * [oliver] We should discuss existing issues that have priority over newly created issues. Some of the new issues are nice-to-have requests. | ||
| * [oliver] Could we stop auto-adding new issues to the agenda? | ||
| * [rob] That risks topics being overlooked. We could auto-add the “needs-agenda” to signal that the topics have not been covered yet. | ||
| * [oliver] We could create a needs-triage label. | ||
| * [rob] Who would triage the labels? | ||
| * [simeon] I will take this task. I have been trying to more consistently comment on new issues. | ||
| * [timothy] I have also been trying to stay on top of issues. | ||
|
|
||
| [Issue 244](https://github.com/w3c/webextensions/issues/244#issuecomment-1291174495): New labels: "breaking change", "topic: localization", "topic: action" | ||
|
|
||
| * [simeon] Topic labels are used as an easy way to group related topics. As we discuss more topics we will probably add more in the future. Any label requests should be discussed in [issue 244](https://github.com/w3c/webextensions/issues/244). | ||
| * [carlos] Edge label is missing? | ||
| * [timothy] Edge label is present. | ||
| * [carlos] But it seems not used. | ||
| * [simeon] We generally ask for explicit support from browser vendors before adding labels. So Mukul, please use the labels where relevant. | ||
| * [mukul] Will do. | ||
| * [rob] Edge is a fork of Chromium, so generally support from Chrome usually implies support in Edge. | ||
|
|
||
| [PR 291](https://github.com/w3c/webextensions/pull/291): Document How we work | ||
|
|
||
| * [simeon] We are in a good position to merge these contribution guidelines. | ||
| * [rob] Should I update the PR with what we just agreed on the process first? | ||
| * [simeon] Let's merge it now. Want to favor multiple iterations of smaller updates. | ||
|
|
||
| (follow-up from TPAC) Check in on status of gathering IDL/JSON for spec work | ||
|
|
||
| * [timothy] I am planning to add a directory to add IDL/JSON files for spec work. | ||
| * [tomislav] We are in the process of generating IDL files from JSON schemas. Depending on timing we could either commit the JSON or the WebIDL. | ||
| * [rob] I know that Chrome and Firefox have implementation details embedded in the JSON/IDL files that are not part of the actual public extension API. These should ideally not be included in the spec. | ||
| * [timothy] This is also the case in the Safari IDL. I am planning to remove this. | ||
| * [simeon] We could also start with the raw version and clean up in updates. | ||
|
|
||
| [Issue 12](https://github.com/w3c/webextensions/issues/12): request: allow to retrieve a frameID from an <iframe> element | ||
|
|
||
| * [simeon] We were all generally supportive of exposing this feature. | ||
| * [rob] Both Firefox and Safari have implemented this. Status of Chrome? | ||
| * [simeon] We have not followed up on this. We like the idea but have not prioritized the implementation. I will try to follow up to get an estimate on when to tackle it. Chrome has a fix-it backlog where engineers can occasionally tackle smaller issues. | ||
|
|
||
| [Issue 188](https://github.com/w3c/webextensions/issues/188): Inconsistency: Permissions "menus" | ||
|
|
||
| * Check-in on support for replacing contextMenus with menus and (2) changing the API signature of menus.create / contextMenus.create | ||
| * [simeon] I have previously expressed that we do not intend to drop the contextMenus namespace. I will post a comment here. | ||
|
|
||
| [Issue 282](https://github.com/w3c/webextensions/issues/282): Proposal: declaring background scripts in a neutral way | ||
|
|
||
| * Check-in on support for declaring bg scripts in a neutral way | ||
| * [simeon] Last night I updated the issue with Chrome's position. We have significant reservations about doing this due to the non-trivial differences between the execution environments. We are open to additional exploration, we are not opposed to a single manifests that works everywhere. We are interested in well-defined semantics. If a developer declares that an extension works in an Event page, a Service worker and a Background page, then it is not obvious whether that is really the case. | ||
| * [rob] The feature request already adds a key to opt in, isn't that a clear enough signal? | ||
| * [simeon] No, we don't think `preferredEnvironment` is not a clear enough signal. That name implies deference rather than an explicit declaration. Maybe it's just a matter of naming. | ||
|
|
||
| [Issue 160](https://github.com/w3c/webextensions/issues/160): Ensure consistency of action.openPopup API across browsers | ||
|
|
||
| * [oliver] I worked with this with Rob and landed a patch in Firefox. There are some edge cases in issue 160. It would be good to get feedback on. | ||
| * [oliver] One of the issues is what to do when another popup is open. Chrome and Safari behave inconsistently. | ||
| * [timothy] Throwing an error when the panel is already is non-actionable by devs. Suggest no-op. | ||
| * [rob] This is not necessarily about opening the popup itself. | ||
| * [rob] Chrome + Safari: please read the list of inconsistencies in issue 160 and comment on the desired behavior. | ||
| * [oliver] How do we want to turn the discussion from this issue into a specification? | ||
| * [simeon] I think that it makes sense to collect the discussion in the issue for future reference when specifying. | ||
| * [rob] Since we don't have a spec yet, should we just put a label on it, or do we already want to start the specification. | ||
| * [simeon] I'd like to err on the side of getting stuff in the spec. | ||
|
|
||
| [Issue 294](https://github.com/w3c/webextensions/issues/294): Proposal: one-time message passing addressed to a specific documentId or contextId | ||
|
|
||
| * [rob] Request here is the ability to send an extension message to a specific frame. Current API has broadcast semantics | ||
| * [simeon] I recall this coming up recently in the transferables discussion. | ||
| * [rob] Indeed, I commented a few hours ago at https://github.com/w3c/webextensions/issues/293#issuecomment-1310203017. | ||
| * [rob] (Firefox) We are supportive of the ability to target a specific frame. | ||
| * [simeon] (Chrome) Supportive of the concept of targeting an individual frame. | ||
| * [timothy] (Safari) Supportive of it. | ||
| * [simeon] Related: runtime.getViews() returns a list of windows, which doesn't work in Service workers. Being able to figure out which context to communicate with would be advantageous. | ||
| * [tomislav] When you introduced documentId, I had concerns over the naming and the applicability to non-documents such as workers. | ||
| * [simeon] The concept of documentId is necessary for our implementation. | ||
| * [rob] It is not a problem to have multiple ways to describe a recipient, as long as the argument is unambiguously identifying one recipient. | ||
|
|
||
| [Issue 300](https://github.com/w3c/webextensions/issues/300): Proposal: Improve the browser.commands API | ||
|
|
||
| * Split up in | ||
| * [Issue 308](https://github.com/w3c/webextensions/issues/308): New api: shortcut changed event | ||
| * [Issue 309](https://github.com/w3c/webextensions/issues/309): Unify the format of Command.shortcut or add a new Command.shortcutKeys property | ||
| * [Issue 310](https://github.com/w3c/webextensions/issues/310): New API: Open Shortcut Setting | ||
| * [simeon] 308: request for a shortcut changed event, (Chrome) supportive, but not a high priority in the backlog. | ||
| * [rob] (Firefox) Supportive too. | ||
| * [timothy] We support shortcuts, but no customization currently. | ||
| * [simeon] 309: Is Jackie here? | ||
| * [jackie] Using information from the commands API I create a shortcut table that is simple to understand. Current shortcuts key is not cross-platform. Propose to add shortcutKeys that is cross-platform, so that the dev does not have to parse the shortcuts string. | ||
| * [rob] I believe that this is a bug in Chrome, where the format of Chrome's shortcut does not match the shortcuts format in the manifest file. In Firefox they are identical. | ||
| * [rob] Let's continue these requests in their own issues, async. There is another topic on the agenda (user scripts) that we should cover, and we are almost out of time. | ||
|
|
||
| [Issue 279](https://github.com/w3c/webextensions/issues/279): User scripts in MV3 | ||
|
|
||
| * [simeon] Chrome is actively working on design and implementation of user scripts in Manifest V3. We have Emilia from the Chrome Eng team who is working on this area. | ||
| * [emilia] Introduces herself and asks for feedback. | ||
| * [rob] To recap, Simeon previously suggested the introduction of the “code” parameter to the scripting API, with appropriate controls for user consent. I have provided some feedback on the issue to improve the security of this design. Emilia has shared a proposal in the issue, and I have commented again earlier today, this time with a detailed analysis of the use case plus API proposals. | ||
| * [rob] Since we only have a few minutes left, I suggest that we continue the discussion on the issue async. If there is any desire to have a quick chat, we can use the WECG chat at https://chat.mozilla.org/#/room/#wecg:mozilla.org. | ||
| * _Several meeting attendees expressed interest in participating in the discussion, but due to meeting conflicts not everyone could join, so we decided to use the chat in lieu of an extended Zoom call._ | ||
|
|
||
| [Issue 304](https://github.com/w3c/webextensions/issues/304): Automatically grant https: host_permissions with http: | ||
|
|
||
| * [carlos] I commented there, there seems to be some confusion on the issue about downgrading permissions. | ||
| * [simeon] Haven't had a chance to read the discussion following the original proposal, so I'm only commenting on the original proposal. We have significant reservations about changing the meaning of a host permission request for a specific protocol (http or https). Implicitly granting https when the developer only declares http is concerning because it grants access to secure transmissions when only insecure were requested. Likewise, automatically granting http when only https is requested is similarly concerning. If developers wish to request both HTTP and HTTPS, there is already a mechanism to do so: `*://`. | ||
| * [rob] Likewise, see my comments in the issue for my position. | ||
| * [carlos] But if the user grants permission it would not be confusing to grant http and https. | ||
| * [rob] That is different. When the user consents to example.com they implicitly grant http and https. The issue is about what we grant if the extension author itself only asks for http. | ||
|
|
||
| The next meeting will be on [Thursday, November 24th, 8 AM PST (4 PM UTC)](https://everytimezone.com/?t=637eb400,3c0). |
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