Agenda discussion for public meeting on 2022-03-31

[oliverdunk]

Please comment on this issue to add topics for our next meeting. The agenda will be finalized two days before the actual meeting and migrated to our meeting notes doc.

Current topic list

@oliverdunk, browser.secureStorage: Discuss how to handle platforms with limited control over authentication methods
@tophf, Performance concerns regarding Offscreen Documents for Manifest V3
@felipeerias, Declarative Net Request proposal: disable individual static rules

[tophf]

Performance concerns regarding #170 Offscreen Documents for Manifest V3, quoting my comment:

The bad thing is that this will increase resource consumption of extensions (roughly twice compared to either SW or the old background page) while the missing features are implemented for the service worker context, which realistically will take more than 5 years, maybe even 10, judging by the two-year lifetime of MV3 during which only a couple of simple features were addressed out of dozens more complex ones. The web specification isn't interested in many/most of these lost features, and even if they were these specifications change extremely slow due to the need to account for a lot of edge cases that matter for the web, but not for extensions.

Coupled with the fact that service workers offer no real benefits over the classic environment for the majority of extensions as both the time to wake up and the memory footprint as well as performance are practically the same, it means that the decision to remove the old DOM-based background pages is premature and should be postponed to ManifestV4. There's just one rare case where a service worker is better: extensions that observe frequent events like network requests while showing an exceptionally heavy UI that can block the extension's main thread e.g. complex extensions for devtools.

For ManifestV3 a much more performant option is to allow both SW and non-persistent background pages, while enticing the developers to migrate by offering preferential treatment of SW-based extensions e.g. shorter reviews and/or some kind of badge in the store and in the browser. Mozilla is doing the right thing here with their support of the limited event pages, which isn't surprising as they have an actual experienced extension developer involved in the design and implementation.

[felipeerias]

Hi, I just joined the CG and would like to propose the discussion of issue #162

Quick summary (taken from the API proposal document):

Extend the declarativeNetRequest API to add a way to disable an individual malfunctioning rule that is part of one of the static rulesets bundled with an extension. This would allow extension developers to react in a timely manner to static rules with undesirable behavior, without hampering the functionality of the extension or risking unwanted side effects.

I am currently working on fixing this problem on Chromium (bug 1225229).

[oliverdunk]

Closing this as the meeting has been and gone now!

[dotproto]

Thanks for creating & closing this, @oliverdunk!