Identify gaps preventing migration to Chrome Manifest V3

[twschiller]

https://developer.chrome.com/docs/extensions/mv3/intro/mv3-migration/

script-src CSP blockers:

• gapi used for Google Sheets, File Picker, Big Query integration, etc.: https://bugs.chromium.org/p/chromium/issues/detail?id=1164452
• Chatlio support widget: https://chatlio.com/ (update: we removed this)

Other potential blockers:

• Background page -> service worker
  • https://developer.chrome.com/docs/extensions/mv3/migrating_to_service_workers/
  • https://developers.google.com/web/ilt/pwa/introduction-to-service-worker
  • They get recycled even if they're processing something: https://github.com/w3c/webextensions/issues/11
  • No access to DOM API (since there's no page)
  • Persisting state across recycling

References:

• MV3 transition timeline: https://developer.chrome.com/blog/mv2-transition/
• Chrome scripting API announcement: https://developer.chrome.com/en/blog/crx-scripting-api/
• API reference: https://developer.chrome.com/docs/extensions/reference/scripting/

[fregante]

Blocked by Firefox’ lack of implementation https://bugzilla.mozilla.org/show_bug.cgi?id=1573659

Given the recent news (WebExtensions Community Group), I'd hope that Google won't block MV2 extensions before Firefox is ready for the MV3.

[twschiller]

The first meeting of the community group was today. One takeaway from the call:

• Chrome is working on an API for in-memory storage that the background service worker can use (this will hopefully address performance limitations of using IDB or local storage). The caveat being that it will likely have a size cap. So we'd continue to use IDB for the local registry and logging

[fregante]

Something I just thought about about non-persistent worker background pages:

• a large (1.9MB) background.js bundle will need to be reloaded "on message" and that will cause intermittent multi-second delays on less recent machines. It might be worth slimming it down or splitting it up for this reason too.

The maximum lifetime of workers is currently 5 minutes, so it's a relatively frequent delay.

[twschiller]

The maximum lifetime of workers is currently 5 minutes

Yes, the bundle size will be a problem in this world. Also, since the background service worker can get recycled at any time, we'll have to build in some resilience into our messaging framework (e.g., retries)

The Chrome team is aware of this problem affecting many popular commercial extensions, you can see the meeting minutes from the last w3c extensions meeting

[fregante]

Retries will be potentially difficult because it depends on what one is retrying. Idempotent requests are fine, POSTs may not be.

An alternative would be to preemptively shut it down while no messages are being handled between 4m and 4m30s, so we never get a 3s message at 4m59s.

Are you aware of any responses that aren't "essentially immediate" other than network requests?

[fregante]

Deadline is in 15 months: https://developer.chrome.com/docs/extensions/mv3/mv2-sunset/

[fregante]

Here's what I gathered in a first pass.

---

Annoyances:

• Firefox does not support MV3 at all yet, it seems. I don't see any public updates regarding that
  • But technically we don't support Firefox officially, so a transition would only push this support farther away
• When using deprecated/renamed APIs, juggling between chrome.* and browser.* APIs will be annoying

I think we have 2 options:

• I focus on MV3 and try to port everything over as soon as possible, without merging until it's done or resolved
• I gradually merge changes but must preserve the extension as MV2-first, thus creating wrappers for those incompatible APIs + probably enabling a webpack transform of the manifest via ENV 👈 ✅

• Chatlio support widget: chatlio.com (update: we removed this)

I still see a few mentions of that code, should I remove all of it?

• gapi used for Google Sheets, File Picker, Big Query integration, etc.: bugs.chromium.org/p/chromium/issues/detail?id=1164452

As one of comments in that ticket mentions, we could get around this by using the raw REST APIs 😬 or perhaps we can find some of these wrapped up on npm, even just as simple helpers.

[fregante]

Initial review closed. Details can be found in:

• https://github.com/pixiebrix/pixiebrix-extension/pull/2107
• https://github.com/pixiebrix/pixiebrix-extension/pull/2106

To recap:

• MV3 doesn't support optional_permissions yet, so the extension will no longer ask to "Grant permissions" on any host.
  • If we do it now and change it later, users will lose access to the hosts they were using because they never granted specific permissions for them.
• Some data is currently stored in-memory in the background page and that will either need to be stored elsewhere or its logic should be changed
  • e.g. don't keep tab references in the background, but fetch them as needed).
  • chrome.storage.session seems to be available in MV3.
• Some actions go through the background and may cross the worker’s maximum lifetime, so we should change them to avoid the background wherever possible.
• We need to review what happens when the worker is killed during an operation. This is currently a hot topic in the MV3 group.
• Firefox does not support MV3 at all, so it's probably easier to wait a bit than having to support both versions.
• Direct gapi.js not available

What we can do now:

• [ ] https://github.com/pixiebrix/pixiebrix-extension/pull/2106
• [ ] https://github.com/pixiebrix/pixiebrix-extension/issues/2156
• [ ] Review the situation/limitations once a month

[fregante]

Mozilla proposed to keep Event Pages around for MV3. They'll still be restartable but we'll continue to have access to some DOM APIs. Unfortunately there's no feedback from the Chrome team yet.

• https://blog.mozilla.org/addons/2022/05/18/manifest-v3-in-firefox-recap-next-steps/
• https://github.com/w3c/webextensions/issues/134

I don't know if other than Axios this is helpful to us anyway.

[twschiller]

I don't know if other than Axios this is helpful to us anyway.

The main background service worker will get recycled every ~5min. So event pages would likely be useful for messaging and coordinating operations across components

[fregante]

The 5 minutes are arbitrary, so if Chrome decides to adopt event pages, they might apply the same limit for MV3.

[fregante]

🚀 I published webext-dynamic-content-scripts with preliminary MV3 support:

• https://github.com/fregante/webext-dynamic-content-scripts/releases/tag/v9.0.0

I will keep testing it in the extension.

[fregante]

Closing now. The extension seems to work on MV3 after https://github.com/pixiebrix/pixiebrix-extension/pull/7214 is merged. We'll tackle new issues as they crop up.