From 26184fc1b4e86b301a2c36af2a66ee5baed2d594 Mon Sep 17 00:00:00 2001 From: Rob Wu Date: Wed, 2 Feb 2022 00:38:51 +0100 Subject: [PATCH 1/2] Fix typo in 2022-01-06 meeting notes --- _minutes/2022-01-06-wecg.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/_minutes/2022-01-06-wecg.md b/_minutes/2022-01-06-wecg.md index cf9b8567..4a1b39b6 100644 --- a/_minutes/2022-01-06-wecg.md +++ b/_minutes/2022-01-06-wecg.md @@ -1,4 +1,4 @@ -# WECG Meetings 2021, Public Notes, Jan 6 +# WECG Meetings 2022, Public Notes, Jan 6 * Chair: Simeon Vincent * Scribes: Rob Wu @@ -13,7 +13,7 @@ Zoom issues? Ping @zombie (Tomislav Jovanovic) in [chat](https://github.com/w3c/ The meeting will start at 3 minutes after the hour. * **Meta-discussion [15 min]** - * Simeon to share some thoughts on how we run these meetings, changs to maximize our time together. [5 min intro, 10 min discussion] + * Simeon to share some thoughts on how we run these meetings, changes to maximize our time together. [5 min intro, 10 min discussion] * **Carry-over from previous meetings [15 min]** * Simeon: Quickly touch on [5 min] * Carlos: move browser specific settings to browser_specific_settings key (https://github.com/w3c/webextensions/issues/115) [10 min] From 0c60556493bba928b044ab022abf6d5633be6990 Mon Sep 17 00:00:00 2001 From: Rob Wu Date: Thu, 20 Jan 2022 19:39:14 +0100 Subject: [PATCH 2/2] Publish minutes of 2022-01-20 meeting --- _minutes/2022-01-20-wecg.md | 125 ++++++++++++++++++++++++++++++++++++ _minutes/README.md | 3 +- 2 files changed, 127 insertions(+), 1 deletion(-) create mode 100644 _minutes/2022-01-20-wecg.md diff --git a/_minutes/2022-01-20-wecg.md b/_minutes/2022-01-20-wecg.md new file mode 100644 index 00000000..9603d1eb --- /dev/null +++ b/_minutes/2022-01-20-wecg.md @@ -0,0 +1,125 @@ +# WECG Meetings 2022, Public Notes, Jan 20 + + * Chair: Tomislav Jovanovic + * Scribes: Rob Wu + +Time: 8 AM PST = https://everytimezone.com/?t=61e8a600,3c0 +Call-in details: [WebExtensions CG, 20th January 2022](https://www.w3.org/events/meetings/d7bbce8f-549f-46ea-b440-ea6902f8707c/20220120T080000) +Zoom issues? Ping @zombie (Tomislav Jovanovic) in [chat](https://github.com/w3c/webextensions/blob/main/CONTRIBUTING.md#joining-chat) + + +## Agenda: [discussion in #144](https://github.com/w3c/webextensions/issues/144), [other issues](https://github.com/w3c/webextensions/issues) + +The meeting will start at 3 minutes after the hour. + + * **Carry-over from previous meetings** + * (nothing) + * **Other new issues** + * #145 Proposals for improving WECG meetings (https://github.com/w3c/webextensions/issues/145) + * #146 Clarify browser vendor positions on APIs in MV3 (https://github.com/w3c/webextensions/issues/146) + * **Open discussion queue (add yourself at the bottom)** + * [Ales Pospichal] Manifest V3 vs native messaging - final decision / next steps on service worker limit (https://github.com/w3c/webextensions/issues/120) + * [Tomislav] #19 request: APIs and infrastructure to simplify cross-browser automated testing of extensions (https://github.com/w3c/webextensions/issues/19#issuecomment-1011492948) + * Mozilla's web-ext https://github.com/mozilla/web-ext + * An existing use case, in lib and CLI form, “cross-browser” (currently uses internal/debugging protocols to do stuff). + * #115 move browser specific settings to browser_specific_settings key (Carlos) (https://github.com/w3c/webextensions/issues/115) + * #147 Inconsistency: determine when non-persistent background pages get suspended (https://github.com/w3c/webextensions/issues/147) + + +## Attendees (sign yourself in) + + 1. Ales Pospichal (I.CA) + 2. Alexei (Privacy Badger) + 3. Rob Wu (Mozilla) + 4. Giorgio Maone (NoScript) + 5. Nick McGuire (1Password) + 6. Carlos Jeurissen (Jeurissen Apps) + 7. Philipp Claßen (Ghostery) + 8. Simeon Vincent (Google) + 9. Oliver Dunk (1Password) + 10. Krzysztof Modras (Ghostery) + 11. Mukul Purohit (Microsoft) + 12. Richard Worth (Capital One) + 13. Emilia Paz (Google) + 14. Bradley Cushing (Dashlane) + 15. Nir Nahum (WalkMe) + 16. Jessie Berlin (Apple) + 17. Tomislav Jovanovic (Mozilla) + 18. Mélanie Chauvel (Dashlane) + 19. Igor Oleinikov (Grammarly) + + +## Meeting notes + +[Issue 145](https://github.com/w3c/webextensions/issues/145): Proposals for improving WECG meetings + + * [simeon] Introduced the topic in the last meeting, and elaborated in issue 145. Not that much to discuss today; encourage everyone to take a look and offer feedback. + * [tomislav] Timeboxing ([issue 144](https://github.com/w3c/webextensions/issues/144)) is a way to run a meeting. That suggestion isn't very controversial. + * [simeon] Idea of “champions” is just thinking aloud loud. Encourage everyone to take a look at the “Keeping meetings productive” section. + * [tomislav] Discussions that can be asynchronous/offline (i.e. in issues on Github) can better be discussed asynchronously. + * [jessie] The "champions" suggestion can really help drive a topic or project to conclusion. + +[Issue 146](https://github.com/w3c/webextensions/issues/146): Clarify browser vendor positions on APIs in MV3 + + * [oliver] Is storage.session API going to be adopted by other browsers? Saw comments about structured cloning, can that be used to store non-JSON data? + * [tomislav] API is going to be the same. Structured cloning may be an option. + * [rob] We haven't started on implementation yet, but broadly it makes sense to have a consistent object serialization format across storage apis + * [jessie] (on behalf of Apple) Policy to not talk about unreleased APIs. The currently released MV3 API in Safari doesn't have storage.session. + * [oliver] cross-extension messaging: will runtime.sendMessage to message other extensions continue to be supported? + * [simeon] On Chrome this API should continue to work as expected. If it doesn't, that's a bug and we should fix it. + * [rob] On Firefox side, no plans to remove it either. + * [jessie] In Safari this API is not implemented. + * [simeon] Let's consider a process for more clearly communicating positions on extension APIs, e.g. using labels on Github. + * [rob] So far the decisions were captured in meeting notes, and in some cases repeated in comments on Github. + +[Issue 120](https://github.com/w3c/webextensions/issues/120): Manifest V3 vs native messaging [Ales Pospichal] + + * [ales] Final decision / next steps on service worker limit? Native messaging app used by extension (smartcard). The app supports a content script via the background, and getting killed after 5 minutes interferes with the extension's functionality. + * [simeon] There are two relevant issues here in Chrome: service worker terminated after 5 minutes ([crbug.com/1152255](https://bugs.chromium.org/p/chromium/issues/detail?id=1152255)) and native messaging host not being terminated on SW disconnect ([crbug.com/1030305](https://bugs.chromium.org/p/chromium/issues/detail?id=1030305)). Neither is intentional. Making it possible for extension SWs to live longer than 5 is one of our top priorities. + * [ales] Timescale for a resolution? + * [simeon] No timeframe. Issue is complicated to address, but we are trying to resolve the native messaging bugs as quick as we can. + +Discussion about webRequest, declarativeWebRequest and MV3 timeline + + * [alexei] Heard repeatedly from Google that MV2 would not be deprecated until MV3 is ready. This is clearly not the case. At this point Chrome Web Store no longer accepts new MV2 extensions, and MV2 stops working entirely in less than a year. Additionally, while the two aforementioned bugs should not require additional work by extension developers, there are others (e.g. non-blocking webRequest not working in SW, SW lifetime) where MV3 extension development is blocked on fixes from Google. While MV2 deprecation is in progress, we have no timeline from Google for any of the critical fixes. + * [tomislav] Firefox does not intend to support the 5 minute limit that Chrome has. + * [bradley] We've tested the Safari preview, and cannot use non-blocking webRequest in its background script. What's the future of non-blocking webRequest across browsers? + * [jessie] Generally, try to avoid keeping the extension alive indefinitely. Would like to hear more about the use cases. + * [krysztof] There are existing examples on the issue tracker, e.g. [issue 72](https://github.com/w3c/webextensions/issues/72), [issue 88](https://github.com/w3c/webextensions/issues/88). The general problem with the declarative API is that advertising technology evolves rapidly and privacy/security extensions will not be able to keep up with declarative API alone. + * [simeon] Keeping service worker alive to observe asynchronously observe network activity is not ideal, but during the design process for MV3 we considered it acceptable middle-ground between constantly keeping the background context alive and totally removing webRequest. + * [tomislav] In Firefox we're keeping blocking webRequest in MV3. We are also interested in ways to improve the performance of common use cases. + +[Issue 19](https://github.com/w3c/webextensions/issues/19): APIs and infrastructure to simplify cross-browser automated testing of extensions + + * [tomislav] We have an existing tool with concrete use cases https://github.com/mozilla/web-ext that already tries to do some of things in this space, in a cross-browser way (firefox+chrome currently), currently via internal/debugging protocols, and we could use that as a starting point for the API surface: + * Loading an extension, enabling, disabling, opening a page and getting test results + * If you know of another cross-browser tool in the same space, also happy to hear and use that for a starting point. + * [simeon] https://github.com/w3c/webextensions/issues/19#issuecomment-1011492948 + * [simeon] Would love to hear community feedback on use cases in WebDriver and extensions. + * [tomislav] On top of the basic ones already mentioned, there are things such as opening extension popups, granting permissions, suspending/waking up background context, messaging to/from extensions, etc. If you already have a project with extensive browser tests, we would love to hear if there are any use cases that we missed. + * [alexei] [Privacy Badger uses Selenium for tests](https://github.com/EFForg/privacybadger/blob/master/doc/tests.md#functional-tests). Your list sounds good. In addition, Selenium lacks native support for opening new windows, requiring hacky workarounds. + * [oliver] At 1Password we also use Selenium. + * [rob] Firefox's extension tests are mostly JavaScript-based, and Firefox already has test utilities that abstract away platform-specific differences (e.g. Firefox desktop vs mobile). + +[Issue 115](https://github.com/w3c/webextensions/issues/115): move browser specific settings to browser_specific_settings key + + * [carlos] Let other browsers align on Firefox/Edge's way of specifying metadata such as minimum version. + * [simeon] Initial feedback from Chrome engineering is hesitation - we ignore unknown keys and could break existing extensions if we were to relocate properties. If the value of this feature is more clear we can reconsider if needed. + * [tomislav] We feel this is useful both for browser vendors and developers. For example, if we decide to support a feature similar to Chrome, but with a different shape, we either have to use another manifest key, or developers have to use separate manifests for different browsers. In general, IMO top level keys are a good match for something that is agreed between browsers, and browser_specific_settings could be used for experimental things (until a final design is agreed between browsers) or for purposefully different things like min/max supported browser versions (which will forever be browser-specific). + +[Issue 147](https://github.com/w3c/webextensions/issues/147): Inconsistency: determine when non-persistent background pages get suspended() + + * [carlos] Had previously raised this in the past. Created an issue because I believe this is something the group should do. + * [tomislav] The details are very implementation-specific, not sure if this is something that can be specified. + * [rob] Are we looking to clarify current behavior or attempt to standardize on a specific set of behaviors? + * [alexei] If everyone were to implement Mozilla's Limited Event page proposal ([issue 134](https://github.com/w3c/webextensions/issues/134)), then we would not have this inconsistency. Still have not heard a satisfactory reason why Google opposes this. + * [simeon] Objective is to minimize lifetime of pseudo-persistent background scripts. Concern with “event pages” is that developers may incorrectly assume that the current behavior of Chrome's MV2 event page is going to be supported. Currently working on getting our proposal into a publicly shareable state. Hoping to have shared in time for the next public session. Comparing these proposals may help clarify our position better than I've been able to. + * [jessie] MV3 consists of several API changes, which may include changes to the “event page” concept. + * [tomislav] It would be great for all browser vendors to come to a consensus on the replacement for background pages as part of MV3. + +(some minutes left) Manager position available at Apple + + * [jessie] Hiring for new manager of Safari's extension team in San Diego. If you are interested, please contact me or apply via the portal at: + * https://jobs.apple.com/en-us/details/200315987/software-engineering-manager-safari-extensions?team=SFTWR + +The next meeting will be on [Thursday, February 3rd, 8 AM PST (4 PM UTC)](https://everytimezone.com/?t=61fb1b00,3c0). diff --git a/_minutes/README.md b/_minutes/README.md index 36d5faec..ca94f9e7 100644 --- a/_minutes/README.md +++ b/_minutes/README.md @@ -10,11 +10,12 @@ After the end of each meeting, meeting notes are published here. ## Upcoming meetings -- 2022-01-20 at 8 AM PST = https://everytimezone.com/?t=61e8a600,3c0 * 2022-02-03 at 8 AM PST = https://everytimezone.com/?t=61fb1b00,3c0 +- 2022-02-17 at 8 AM PST = https://everytimezone.com/?t=620d9000,3c0 ## Past meetings +* 2022-01-20 ([minutes](2022-01-20-wecg.md)) * 2022-01-06 ([minutes](2022-01-06-wecg.md)) * 2021-12-09 ([minutes](2021-12-09-wecg.md)) * 2021-11-11 ([minutes](2021-11-11-wecg.md))