Add support/migrate to MV3

[LLCampos]

Manifest V3 for Chrome Extensions was introduced recently.

Currently the code only supports MV2.

[AlexITC]

What's the state for the Manifest V3 in Firefox? I don't plan to do such migration unless it's supported by Firefox (I couldn't find their current state), also, this should be implemented in the plugin (https://github.com/AlexITC/scala-js-chrome) first.

Feel free to raise a PR.

[phdoerfler]

Little known fact: Safari has also added support for Manifest v2 extensions. Regarding support for MV3: A quick search brought up this 12 months old forum post stating:

Safari 14 only supports manifest v2. Manifest v3 is still in development, and it is not currently shipping in any browser. We can't comment on future Safari releases.

[AlexITC]

Apparently, this needs to get done soon (see), first thing is to get it done in github.com/AlexITC/scala-js-chrome

[phdoerfler]

Indeed. In particular:

January 17, 2022: New Manifest V2 extensions will no longer be accepted by the Chrome Web Store. Developers may still push updates to existing Manifest V2 extensions, but no new Manifest V2 items may be submitted.

[AlexITC]

Indeed, that makes the template/plugin not very useful because people won't be able to publish to the chrome web store.

I'm yet to find what exactly needs to change, hoping that it isn't much work.

I'll keep the ticket opened to post updates.

[phdoerfler]

I gingerly prodded at the generated manifest to see how quickly it falls apart when changing "manifest_version": 2, to "manifest_version": 3,: Aside from this, a major, necessary change is: https://developer.chrome.com/docs/extensions/mv3/migrating_to_service_workers/

Where scripts supported multiple scripts (which the template makes use of), service_worker only supports one single .js file. Currently these scripts are:

• scripts/common.js (just holds one small facade that makes it easier to interact with some JS from Scala)
• main-bundle.js (the main event)
• scripts/background-script.js (just has a single line runOnBackground();)

These would need to be fused into one, e.g., by a) merging them all into main-bundle.js or b) by having one hand written js file containing the code of common.js and background-script.js and calling main-bundle.js, if that is possible. Lastly c), there's the hacky way of generating a js file that is a sensible merge of all three of these js files using an sbt task, partially automating Approach b. It remains to be seen if that is a sensible thing to do.

To be clear, a simple concatentation won't suffice, because event handling changed. As the docs point out:

First, service workers are terminated when not in use and restarted when needed (similar to event pages). Second, service workers don't have access to DOM.

The docs also elaborate on how these two issues can be addressed.

[AlexITC]

@phdoerfler thanks for sharing the issues you have found, the migration to service workers is the major change I have found.

As you point out, we can trick the build to produce a single js.

I have been waiting to see how Metamask handles this migration.

[phdoerfler]

I see, thanks for the update! It doesn't seem like Metamask is willing to share their findings, no? It might be that we have to rely on Chrome's documentation and experimentation.

Speaking of: I have concatenated all three files, just to see what other parts of the manifest are an issue. The next issue was thus revealed:

Error at key 'web_accessible_resources'. Parsing array failed at index 0: expected dictionary, got string

Continuing in this Frankenstein spirit, replacing:

"web_accessible_resources": [
  "icons/*",
  "scripts/common.js",
  "main-bundle.js",
  "scripts/active-tab-website-script.js"
]

with:

"web_accessible_resources": [{
  "resources": [
    "icons/*",
    "scripts/common.js",
    "main-bundle.js",
    "scripts/active-tab-website-script.js"
  ],
  "matches": ["https://www.example.com/*", "https://www.example.de/*"]
}],

got Chrome to accept the manifest. So far, so good. Unsurprisingly, the extension fails to load because of what I tried to sell Chrome as a "service worker":

It is, again, not too surprising that a simple concatenation of the background scripts did not suffice. As I previously mentioned, the event handling works differently than before.

FWIW, you probably came to similar findings yourself already. Just thought I'd share what doesn't work so the next one does not have to repeat these mistakes but can instead make new ones 😉

[AlexITC]

I see, thanks for the update! It doesn't seem like Metamask is willing to share their findings, no? It might be that we have to rely on Chrome's documentation and experimentation.

If anyone wants to upgrade soon, for sure, we should rely on the public docs + trial and error, in my personal case, I do not have this as a blocker which is why I have been waiting until Metamask releases the support for MV3, even if they do not share their analysis, the code should get in their repo some day.

Unsurprisingly, the extension fails to load because of what I tried to sell Chrome as a "service worker":

I do not remember much about this but I understand that the service worker api for websites has slightly different apis available for extensions (which could differ from what background context has in MV2), which could explain problems like the one you are facing.

A quick search makes me believe that we could import many js files for a service worker:

• https://stackoverflow.com/questions/66406672/chrome-extension-mv3-modularize-service-worker-js-file
• https://developer.chrome.com/docs/extensions/mv3/migrating_to_service_workers/

[phdoerfler]

Any news on this?

[AlexITC]

Unfortunately, I haven't had a chance to look into this, right now I'm not actively working on any browser extension.