Skip to content

Latest commit

 

History

History
125 lines (97 loc) · 11.6 KB

2022-01-20-wecg.md

File metadata and controls

125 lines (97 loc) · 11.6 KB
Raw

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 Zoom issues? Ping @zombie (Tomislav Jovanovic) in chat

Agenda: discussion in #144, other 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 (#145)
    • #146 Clarify browser vendor positions on APIs in MV3 (#146)
  • Open discussion queue (add yourself at the bottom)
    • [Ales Pospichal] Manifest V3 vs native messaging - final decision / next steps on service worker limit (#120)
    • [Tomislav] #19 request: APIs and infrastructure to simplify cross-browser automated testing of extensions (#19 (comment))
    • #115 move browser specific settings to browser_specific_settings key (Carlos) (#115)
    • #147 Inconsistency: determine when non-persistent background pages get suspended (#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: 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) 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: 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: 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) and native messaging host not being terminated on SW disconnect (crbug.com/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, issue 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: 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] #19 (comment)
  • [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. 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: 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: 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), 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

The next meeting will be on Thursday, February 3rd, 8 AM PST (4 PM UTC).