-
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.
Publish minutes of 2021-12-09 meeting
- Loading branch information
Showing
2 changed files
with
128 additions
and
1 deletion.
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,126 @@ | ||
| # WECG Meetings 2021, Public Notes, Dec 9 | ||
|
|
||
| * Chair: Timothy Hatcher | ||
| * Scribes: Rob Wu | ||
|
|
||
| Time: 8 AM PST = https://everytimezone.com/?t=61b14700,3c0 | ||
| Call-in details: [WebExtensions CG, 9th December 2021 event](https://www.w3.org/events/meetings/d7bbce8f-549f-46ea-b440-ea6902f8707c/20211209T080000) | ||
| 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) | ||
|
|
||
| * **Carry-over from previous meetings** | ||
| * Limited event page (https://github.com/w3c/webextensions/issues/134) | ||
| * Background page vs service worker use case (https://github.com/w3c/webextensions/issues/120) | ||
| * **Other new issues** | ||
| * Support i18n.getMessage API in serviceWorker (https://github.com/w3c/webextensions/issues/93) | ||
| * expose more mv3 APIs to mv2 (https://github.com/w3c/webextensions/issues/118) | ||
| * neutral API names (https://github.com/w3c/webextensions/issues/113) | ||
| * move browser specific settings to browser_specific_settings key (https://github.com/w3c/webextensions/issues/115) | ||
|
|
||
|
|
||
| ## Attendees (sign yourself in) | ||
|
|
||
| 1. Giorgio Maone (NoScript) | ||
| 2. Jack Works (Sujitech) | ||
| 3. Rob Wu (Mozilla) | ||
| 4. Tomislav Jovanovic (Mozilla) | ||
| 5. Oliver Dunk (1Password) | ||
| 6. Nick McGuire (1Password) | ||
| 7. Timothy Hatcher (Apple) | ||
| 8. Nick Doty (Center for Democracy & Technology) | ||
| 9. Carlos Jeurissen (Jeurissen Apps) | ||
| 10. Peter Snyder (Brave Software, PING Co-Chair) | ||
| 11. Alexei (Privacy Badger) | ||
| 12. Simeon Vincent (Google) | ||
| 13. Devlin Cronin (Google) | ||
| 14. Mukul Purohit (Microsoft) | ||
| 15. Sam Macbeth (DuckDuckGo) | ||
| 16. Bradley Cushing (Dashlane) | ||
| 17. Philipp Claßen (Ghostery) | ||
| 18. Krzysztof Modras (Ghostery) | ||
| 19. Daniel Glazman (Dashlane) | ||
| 20. Nir Nahum (WalkMe) | ||
| 21. Andrey Meshkov (AdGuard) | ||
| 22. Mélanie Chauvel (Dashlane) | ||
|
|
||
|
|
||
| ## Queue (add yourself at the bottom) | ||
|
|
||
| * <add yourself> | ||
|
|
||
|
|
||
| ## Meeting notes | ||
|
|
||
| [Issue 134](https://github.com/w3c/webextensions/issues/134): Limited event pages | ||
|
|
||
| * [timothy] We have shipped this in [our latest Safari technology preview](https://webkit.org/blog/12137/release-notes-for-safari-technology-preview-136/) - MV3 + event pages. "persistent" key is ignored | ||
| * [tomislav] Firefox is working on the details to implement event pages. | ||
| * [timothy] In Safari, if there is no activity after 30 seconds the event page is shut down. | ||
| * [krzysztof] Hitting this 30 seconds in practice already, would be nice if this timer can be relaxed. | ||
| * [glazou] Please discuss the limit with developers. | ||
| * [timothy] Willing to reconsider duration. Looking for the right balance between keeping in memory and the overhead of starting the event page. 30 seconds of no messages. If an event fires, the timer is reset | ||
| * [alexei] Please consider that this may be premature optimization that hurts all extensions. Consider the memory utilization of websites, how the service worker for Twitter.com alone likely uses more memory than a typical extension. Users have many more websites open than extensions. | ||
| * [rob] We should discuss establishing a consistent set of rules for when a background context will be terminated. Developer and implementer feedback is very welcome. | ||
| * [glazou] We're deep in the implementing mv3 versions, we need these details ASAP. | ||
|
|
||
| [Issue 120](https://github.com/w3c/webextensions/issues/120): Background page vs service worker use case | ||
|
|
||
| * [timothy] Just discussed the limited event pages proposal, I believe Devlin also had an idea he wanted to discuss. | ||
| * [devlin] Happy to give an overview. Targeting use cases that need DOM, but expressly not targeting lifetime issues. We're looking to address those issues separately. | ||
| * [devlin] We recognize there's hesitation among developers and don't mean to trivialize the amount of work this will take. We believe SWs have a number of benefits, especially with respect to the number of processes being used. Especially a constraint for low end devices. Obviously, at Google Chromebooks are an important consideration for us. | ||
| * [devlin] These don't have to be vanilla service workers. We can extend and customize them for our use cases. One of the things we're looking for on the Chrome side is adding the ability for an extension to create a temporary DOM context with an explicitly declared purpose. Allows the browser to surface this purpose to the end user and help reviewers detect malicious uses of this capability. | ||
| * [glazou] Question: you said something about threading. Nested workers are currently not possible, it should be. | ||
| * [devlin] Agreed that spawning workers from a Service worker would be desirable. | ||
| * [nick] Is there any way we could move forward with service workers without having lifetime considerations? | ||
| * [devlin] I don't think we'd do something with no lifetime considerations. We may do something with an appropriate lifetime. As Timothy said, it's a balancing act. There are legitimate use cases that require longer execution time, but there's also a lot of extensions where that doesn't make sense. The user shouldn't need to understand how an extension is implemented. It should just work and be a good experience. I do think we'll need to adjust these limits, but not completely remove the limits. | ||
| * [nick] Also from 1Password, so similar concerns as glazou raised (e.g. getting shut down during sync). Realize unbounded execution context is not feasible, but many of our operations (e.g. cryptographic work) requires more time and being killed aggressively requires us to burn more resources to be useful to the user. | ||
| * [glazou] Agree, the original reason to shut down SW might have the exact opposite effect on resource usage. Also complexify our code by an order of magnitude. | ||
| * [devlin] There are absolutely pessimistic cases where total resource utilization is greater in the event based model. Again, as Timothy said it's a balance. | ||
| * [alexei] Just opened devtools in Chrome and looking at extension and web page memory usage. E.g Privacy Badger extension has 40k, the Google doc for this meeting and Gmail are each using 10x+ that. Don't believe that memory usage is a good argument. Not enough to claim "Google cares about low end devices,” where is the data that justifies forcing all extensions to become ephemeral? | ||
| * [tomislav] Requiring extensions to be prepared to be shutdown is separate from how often they will be shut down. Agree that terminating an insignificant 40kb extension on desktop is a failure of the browser. That said, it's important for extensions to be prepared to be terminated and restarted as needed. | ||
| * [rob] Extensions should be designed to be shut down at any time. Extensions should be prepare for this and ensure that the user experience is not overly impacted. | ||
| * [tomislav] In Firefox currently all extensions share a single process, so a single crash can take down others. Trying to work past that, but that will take time. | ||
| * [rob] If extension developers need more API support to properly account for shutdowns, file new issues/feature requests. | ||
| * [bradley] The gap and challenge for extension developers is that we are now being asked to move from an environment where we can expect stable, long lasting execution to being terminated at any point. | ||
| * [krzysztof] Where can we provide feedback to influence the direction of the platform? | ||
| * [devlin] The WECG repository is a good place. We look at the filed issues, though we do not always have time to respond to every issue individually. Focus on use cases rather than very specific API requests that have a narrow use case, since a use case may be implemented in ways other than a specific API request. | ||
|
|
||
| Random Q&A related to MV3: | ||
|
|
||
| * [andrey] Could we discuss timing of MV3 implementation and MV2 deprecation? In less than 30 days we cannot update MV2 extensions to the Chrome Web Store. Can we change the timeline? | ||
| * [devlin] No plans currently. May change in the future, but at present it's not likely. Existing extensions can still update MV2 extensions. | ||
| * [andrey] There are still broken use cases, like native messaging, would you consider some exceptions? | ||
| * [devlin] The native messaging issue is a bug, not part of the design of MV3. If anyone here had a use case for native messaging, I'd recommend uploading a placeholder MV2 extension today. | ||
| * [andrey] Do you think fixing lifetime (and DOM issues) would realistically be resolved during 2022? | ||
| * [devlin] Hesitant to say "resolve”, but it will be prioritized. There will be significant changes to address the lifetime concerns. | ||
| * [alexei] Will observational webRequest ever be [fixed in Manifest V3](https://bugs.chromium.org/p/chromium/issues/detail?id=1024211)? | ||
| * [devlin] Yes. | ||
| * [carlos] Does Google consider other chromium browsers with respect to the Manifest V3 timeline? | ||
| * [devlin] Very much want to be an open source browsers that others can fork and modify, but must also consider our own browser. Want to make sure that we're doing what's best for Chrome without negatively impacting 3rd parties. Won't intentionally make it hard for other vendors. | ||
| * [glazou] Suggest Google hold an open event with extension vendors to discuss Manifest V3 issues, strategy and timeline | ||
| * [rob] File issues in the WECG (or issue trackers for vendor-specific bugs) | ||
|
|
||
| [Issue 93](https://github.com/w3c/webextensions/issues/93): Support i18n.getMessage API in serviceWorker | ||
|
|
||
| * [carlos] Simeon mentioned in the past that there are issues with this method that may require design changes. Can you clarify? | ||
| * [devlin] An issue with the implementation is that it's synchronous. [spoke to Chrome implementation details related to process responsibility, message passing between processes, challenges in supporting synchronous responses, and use cases that currently require synchronous responses] | ||
|
|
||
| [Issue 118](https://github.com/w3c/webextensions/issues/118): expose more mv3 APIs to mv2 | ||
|
|
||
| * [timothy] In Safari we do expose scripting in MV2. Anything else besides scripting? | ||
| * [carlos] Another API is the ability to find out whether an action button is pinned on the toolbar. It's not available in MV2, only in MV3, but useful. | ||
| * [devlin] From the Google side we'd like to support new APIs in MV3, because MV2 is deprecated and supporting new APIs in MV2 adds to the maintenance burden. It's also an incentive for developers to migrate to MV3. We'll fix high-priority bugs in MV2, but MV3 is priority. | ||
| * [tomislav] Disagree with viewpoint, it makes transitioning harder. Our plans are to support APIs in MV2 where possible. | ||
| * [timothy] Safari also has that philosophy. We'll also support service workers in MV2. | ||
| * [devlin] For this reason we support service workers and DNR in MV2 in Chrome. Some other APIs have a less drastic migration and are more utilities than dramatic replacement features, e.g. the action API replaces the browserAction API and is not supported in MV2 because migration is straightforward. | ||
| * [rob] Firefox develops new features restricted to MV3, to land partial implementations of an API. When an API implementation is done, the MV3 restriction will be lifted. | ||
|
|
||
| [Issue 113](https://github.com/w3c/webextensions/issues/113): neutral API names | ||
|
|
||
| * [tomislav] Since devlin is here: Would you consider "browser” as a browser-neutral alias to chrome? | ||
| * [devlin] We'll think about that. | ||
| * (ran out of time, keep it for next time - see you next year) | ||
|
|
||
| The next meeting will be on [Thursday, January 6th, 8 AM PST (4 PM UTC)](https://everytimezone.com/?t=61d63100,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