WebExtension manifest v3

[toasted-nutbread]

The Google Chrome team is working on a version 3 of the WebExtension manifest. While the timelines are still indeterminate at this point, it's better to start tracking and thinking about the changes this will entail sooner rather than later. We should use this issue to document any potential problems we may encounter.

Relevant links:

• [Google] Migrating to Manifest V3
• [Mozilla] Mozilla’s Manifest v3 FAQ

Noteworthy points:

Are you currently using chrome.tabs.executeScript({code: '...'}), eval(), or new Function() in background contexts or content scripts?

• Move all external code (JS, Wasm, CSS) into your extension bundle.
• Update script and style references to load resources from the extension bundle.
• Use chrome.runtime.getURL() to build resource URLs at runtime.

This will present an issue with Handlebars.js, since it uses Function constructor to dynamically eval code.

Are you currently using chrome.runtime.getBackgroundPage(), chrome.extension.getBackgroundPage(), chrome.extension.getExtensionTabs(), or chrome.extension.getViews()?

• Migrate to passing messages between other contexts and the background service worker.

This is planned and in progress. Already started here: #447.

Are you currently using chrome.runtime.getBackgroundPage(), chrome.extension.getBackgroundPage(), chrome.extension.getExtensionTabs(), or chrome.extension.getViews()?

• Migrate to passing messages between other contexts and the background service worker.

This is potentially the biggest change, and will affect at least a few things that I am aware of.

• Service workers have no DOM, so the clipboardPasteTarget shenanigans won't work. Not sure what the workaround for that would be.
• Service workers lifetime is a bit odd, as they can be terminated to save memory. It seems there are ways to keep a service worker alive, but the browser may still kill it for other reasons, "such as infinite loops and tasks exceeding imposed time limits (if any) while handling the events." Not sure exactly how this will function in practice, or if extensions are granted more leniency.
• IndexedDB access is still present.

Related:

• [Google] Migrating from Background Pages to Service Workers
• [W3C] Service Workers Spec

---

Originally mentioned in #353 (comment), but this is worth its own issue.

[siikamiika]

Are you currently using chrome.tabs.executeScript({code: '...'}), eval(), or new Function() in background contexts or content scripts?

• Move all external code (JS, Wasm, CSS) into your extension bundle.
• Update script and style references to load resources from the extension bundle.
• Use chrome.runtime.getURL() to build resource URLs at runtime.

This will present an issue with Handlebars.js, since it uses Function constructor to dynamically eval code.

This is quite worrying since custom Handlebars templates can be very important to some users. I wonder if there's a fork fixing the issue. handlebars-lang/handlebars.js#1443 (comment)

• Service workers have no DOM, so the clipboardPasteTarget shenanigans won't work. Not sure what the workaround for that would be.

navigator.clipboard.readText will work on Firefox, but on Chrome it will be quite useless because they don't allow reading clipboard in the background. Since the manifest is still not finalized, I think we should search the bug tracker for any issues mentioning this problem and tell about our use case, or create a new issue.

[toasted-nutbread]

https://bugs.chromium.org/p/chromium/issues/detail?id=1063219
https://bugs.chromium.org/p/chromium/issues/detail?id=896897#c12
https://groups.google.com/a/chromium.org/forum/#!forum/chromium-extensions

[toasted-nutbread]

List of tasks that would need addressing:

• Dictionary images #446 (comment)

[toasted-nutbread]

https://developer.chrome.com/apps/sandboxingEval

[toasted-nutbread]

Doing some brief testing with v3, I've noticed the following:

• The service worker must be a single file. Therefore, what we are currently doing on the background.html page with multiple <script src="..."></script> tags will not work. require is also not available. The only solution would appear to be compiling all scripts into a single service worker file.
• Message listeners such as chrome.runtime.onMessage should be set up immediately in the service worker in order to ensure that the messages are not dropped. For example:

  // This must be done before any async calls occur.
  chrome.runtime.onMessage.addListener((message, sender, callback) => {
      // Handle
  });
  
  // Rather than something like this, which can result in
  // dropped packets if the service worker was previously stopped.
  (async () => {
      await Promise.resolve();
      chrome.runtime.onMessage.addListener((message, sender, callback) => {
          // Handle
      });
  })();

• The events used on the background page are:
  • chrome.commands.onCommand
  • chrome.tabs.onZoomChange
  • chrome.runtime.onMessage
  • chrome.runtime.onConnect

[toasted-nutbread]

Branch for switching to declarative web request, eventually:
https://github.com/toasted-nutbread/yomichan/commits/declarative-web-request

For some reason, this does not actually strip the Origin header, so the jpod101-alternate source doesn't work correctly. Unclear if this is a bug or if I'm not using the APIs/fetch correctly.

[toasted-nutbread]

New branch for switching to declarativeNetRequest, which replaces declarativeWebRequest.
https://github.com/toasted-nutbread/yomichan/commits/declarative-net-request

This version does seem to work correctly, contrasted with the old declarativeWebRequest.

[toasted-nutbread]

As of now, despite the broken and sometimes non-existent documentation, MV3 is now supported with the build variant chrome-mv3. The main feature that is currently not supported is clipboard observation from the background page, since there is no DOM to read the clipboard from in MV3. I opened an issue about this here: https://bugs.chromium.org/p/chromium/issues/detail?id=1160302