-
Notifications
You must be signed in to change notification settings - Fork 62
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 #23 from w3c/meeting-2021-06-24-wecg
Publish minutes of 2021-06-24 meeting
- Loading branch information
Showing
1 changed file
with
169 additions
and
0 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,169 @@ | ||
| # WECG Meetings 2021, Public Notes, June 24 | ||
|
|
||
| * Chair: Timothy Hatcher | ||
| * Scribes: Mukul Purohit, Rob Wu | ||
|
|
||
| Call-in details: https://lists.w3.org/Archives/Member/internal-webextensions/2021Jun/0000.html | ||
| 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) | ||
|
|
||
| * [Issue 1](https://github.com/w3c/webextensions/issues/1): What to do with the older CG? | ||
| * Consensus: take useful parts out, instead of inheriting the old doc directly. | ||
| * [Issue 13](https://github.com/w3c/webextensions/issues/13): Where do we start for a draft? | ||
| * Choices: | ||
| * ✔ Manifest format | ||
| * terms | ||
| * [Issue 9](https://github.com/w3c/webextensions/issues/9): New Issue Template | ||
| * Template: New feature requests | ||
| * Template: Cross-browser compatibility | ||
| * Template: Missing functionality in Manifest V3 (Concerns about the status quo) | ||
| * Add issue tags to categorize those issues | ||
| * [Issue 21](https://github.com/w3c/webextensions/issues/21): Discussing the scope of the draft (linked to 13 maybe?) | ||
| * To be discussed later | ||
|
|
||
|
|
||
| ## Queue (add yourself at the bottom): | ||
|
|
||
| 1. Oliver Dunk, 1Password: | ||
| * Discuss and encourage adoption of browserAction.openPopup (https://github.com/w3c/webextensions/issues/15) | ||
| * request: allow to retrieve a frameID from an `<iframe>` element (https://github.com/w3c/webextensions/issues/12) | ||
|
|
||
| 2. Todd Schiller, PixieBrix | ||
| * Meta: How should we think about use of meeting time vs. collaboration outside of the meetings? For example: some of the issues below require design work to help flesh out the request | ||
| * WebExtensionWorker instead of Service Worker (https://github.com/w3c/webextensions/issues/11) | ||
| * request: provide sandboxed execution environment for template engines and data transformation (https://github.com/w3c/webextensions/issues/18) | ||
|
|
||
| 3. Don Hopkins, Ground Up Software | ||
| * Discuss built-in and extension support for pie menus, tabbed windows, global mouse tracking, cursor position setting, customization, automation, permissions and security, and other issues relating to non-rectangular, partially transparent, full screen tracking user interfaces. Commented on https://github.com/w3c/webextensions/issues/15 but would appreciate advice about creating separate issues. | ||
| * Interested in Oliver Dunk’s discussion of browserAction.openPopup for implementing non-rectangular / transparent user interfaces like pie menus, tabbed windows, etc (I’ve left some comments on the issue), and integrating pie menus with browser customization and automation extensions like Todd Schiller’s PixieBrix. | ||
|
|
||
|
|
||
| ## Attendees (sign yourself in): | ||
|
|
||
| 1. Tomislav Jovanovic (Mozilla) | ||
| 2. Timothy Hatcher (Apple) | ||
| 3. Todd Schiller (PixieBrix) | ||
| 4. Rob Wu (Mozilla) | ||
| 5. Mukul Purohit (Microsoft) | ||
| 6. Simeon (Google) | ||
| 7. Nick McGuire (1Password) | ||
| 8. Jessie Berlin (Apple) | ||
| 9. Marwan Liani (Dashlane) | ||
| 10. Jon Howard (EasyFundraising) | ||
| 11. Bradley Cushing (Dashlane) | ||
| 12. Mélanie Chauvel (Dashlane) | ||
| 13. Theresa O’Connor (Apple) | ||
| 14. Daniel Glazman (glazou, Dashlane) | ||
| 15. Jack Works (Mask Network) | ||
| 16. Thierry Régagnon (Dashlane) | ||
| 17. Shane Caraveo (Mozilla) | ||
| 18. Brandon Lucier (1Password) | ||
| 19. George Henderson (Capital One) | ||
| 20. Don Hopkins (Ground Up Software) | ||
| 21. Oliver Dunk (1Password) | ||
| 22. Mitch Cohen (1Password) | ||
| 23. Josh Rampersad (1Password) | ||
| 24. Dalton Downing (1Password) | ||
| 25. Kiky Tangerine (Grammarly) | ||
| 26. Ellie Epskamp-Hunt (Apple) | ||
| 27. Richard Worth (Capital One) | ||
| 28. Caitlin Neiman (Mozilla) | ||
|
|
||
|
|
||
| --- | ||
|
|
||
|
|
||
| ### Administrative Questions | ||
|
|
||
| Q: Do I need a Zoom account? | ||
| A: Yes if you plan on using the web client. | ||
|
|
||
| Q: I want to discuss a topic that doesn’t have a Github issue? | ||
| A: Add your name (and topic) to the Queue, the chair will call on you. | ||
|
|
||
|
|
||
| ## Meeting notes | ||
|
|
||
| Introduction by Chair and Editors | ||
| Tim Hatcher | ||
| Simeon | ||
| Tomislav, | ||
| Mukul, | ||
|
|
||
| [Issue 1 - What to do with the older CG?](https://github.com/w3c/webextensions/issues/1) | ||
|
|
||
| * [daniel] What’s the interoperability with the current/old spec? | ||
| * [timothy] There was earlier discussion around Namespace (browser / chrome), Promises etc. | ||
| * [hober] starting from the browser-ext spec vs from scratch is mainly a productivity concern. That being said, duplicating effort isn’t great either. Do the current editors want to re-use it or start fresh? | ||
| * [tomislav] Some of the items mostly Manifestv2 specific can be copy-pasted (but not whole ofAPIs]. Start from scratch but we can incorporate stuff from old document | ||
| * [simeon] From the Chrome side, specifying the current state of Manifest v2 is not necessarily a goal. It would be useful to specify the common parts of manifest v2 and manifest v3, e.g. content scripts. | ||
| * [daniel] What would be the policy regarding implementation by implementers? | ||
| * [tess] intent is to Spec something which is broadly interoperable and implement it | ||
| * [simeon] goal of this CG initially is to figure out how to work together, and work towards future standardization. Identifying gaps in common core and find the common solution and create the platform to be more consistent across browsers. Last point in the charter is to keep the divergence aspect which is my idea of standardization | ||
| * [timothy] Apple and Mozilla don’t have implementation of MV3, so they wont have clarity wrt implementation challenges of a serviceworker or other MV3 specific items. | ||
| * [jack] Are all implementers participating in this group? | ||
| * [rob] Yes (Apple, Mozilla, Microsoft and Google are founding members of this group) | ||
| * [simeon] Earlier browser-ext group had challenges as implementers were not onboard | ||
| * [timothy] Manifest format and isolated world has not changed in years, and we need to write it down. Issue 13 is where do we start. I propose that we start with Manifest format | ||
| * [jack] Start with scope and terminologies | ||
| * [daniel] talked about css group approach | ||
| * [tess] different groups can use different approach. | ||
| * [tomislav] We have defined in charter what we plan to do | ||
| * [george] Starting with manifest and table-of-content | ||
| * [timothy] **RESOLVED** issue 1: consensus is to start with a new spec, and take pieces from the old spec where useful. | ||
| * Post on issue and ask for feedback from Florian. | ||
| * [simeon] open to any other ideas about the charter | ||
| * [hober] noting that this meeting time works for US/EU/India, but not for people in Japan (e.g. Florian). Propose to have two alternating time slots to cover the globe. | ||
| * Daniel and timothy agree and propose that we discuss it sometime | ||
|
|
||
| [Issue 13](https://github.com/w3c/webextensions/issues/13): Where do we start for a draft? | ||
|
|
||
| * [timothy] I propose that we start with manifest | ||
| * [simeon] similar issue (https://github.com/w3c/webextensions/issues/14) wrt differences in | ||
| * [todd] from linter perspective warn about unrecognized properties, but ignore in implementations. | ||
|
|
||
| [Issue 9](https://github.com/w3c/webextensions/issues/9): New Issue Template | ||
|
|
||
| * [timothy] I open for discussion | ||
| * [timothy] there are few buckets - full on new things v/s existing implementation. Does github allows multiple templates? | ||
| * [todd] Where MV3 is going wrt ambiguities could be another template; e.g service workers issues | ||
| * Some discussion around github support for multiple templates | ||
| * [timothy] **RESOLVED** We can start with 3 templates | ||
|
|
||
| [Issue 21](https://github.com/w3c/webextensions/issues/21): Discussing the scope of the draft (linked to 13 maybe?) | ||
|
|
||
| * [melanie] (=issue author) discuss later | ||
|
|
||
| Service worker topic | ||
|
|
||
| * [simeon] Chrome’s response around issues with service-worker like document parsing, audio. Aims to improve service workers instead of just adding extension-specific APIs. | ||
| * [jack] raised an issue (https://github.com/w3c/webextensions/issues/11). Proposes to use a dedicated worker type instead of a service worker | ||
| * [jack] Raised issue about Chrome’s implementation that forcibly terminates workers in 5 minutes, and extension developers using hacks to work around it. | ||
| * [daniel] burden on extension vendors to move to stateless from stateful. We need to maintain state and losing performance. | ||
| * [timothy] Persistent issue of storage is good issue to file | ||
| * [todd] What is our philosophy around desktop v/s mobile. Practical limitation with IndexedDB and local storage. | ||
| * [simeon] Chrome is pursuing another mechanism with storage.session with limited capacity, e.g. to support password managers that need to store a master password. | ||
| * [daniel] limiting the size in storage is not doable. | ||
| * [timothy] we should get back when discussing the storage specific issues | ||
|
|
||
| Oliver Dunk, 1Password issues | ||
|
|
||
| * [oliver] https://github.com/w3c/webextensions/issues/15 popup specific use-cases being described. FF has this implemented but there are limitations (requiring user interaction). Chrome has implemented to certain extensions like chrome-cast | ||
| * [jack] we also use that in our technology. Is it relevant as this is similar to window.open | ||
| * [timothy] there is a distinction between extension popup and window.open. If CS want to open a popup than message-pass should allow | ||
| * [simeon] permission.request. | ||
| * [simeon] On exposing more APIs to content scripts: this is major security concern (speaking for Chrome implementation) | ||
| * [rob] From Mozilla perspective, agreed. | ||
| * [daniel] support the idea. | ||
| * [timothy] would like to hear from others | ||
| * [jack] suggest to freeze new feature request until spec has been written | ||
| * [tomislav] What should be the output of this CG. Start writing the common behaviours, and expand on it. | ||
| * [daniel] Disagree with tomislav. This CG is based on the charter. As per that, disallowing a wishlist would be a problem | ||
| * [timothy] what should we do with new ideas. There was a discussion, and the suggestion was to file an issue, although we understand that it won't be resolved soon | ||
| * [simeon] we are not just trying to pursue a spec, but also the browser vendors are given a platform to discuss new implementations. Browsers have more tasks than time/people to work on it. Having more thing in backlog would be a best approach. Expectation setup - issues filed need not be implemented in next quarter or so would be incorrect expectation. | ||
| * [tomislav] focus on the initial tasks of the CG to document | ||
| * [timothy] brief discussion in this forum for new ideas is fine. | ||
| * [rob] Emphasize that this group is not the only place to discuss features. Browser-specific issue trackers can still be used to have discussions with browser vendors. | ||
| * [timothy] we would end today. Will be back in 2 weeks. |