Migrate to manifest v3 for browser extensions

[mossroy]

Chrome introduced a version 3 of the extensions manifest format : https://developer.chrome.com/docs/extensions/mv3/intro/
Edge is following, as it's now based on Chromium : https://blogs.windows.com/msedgedev/2020/10/14/extension-manifest-chromium-edge/
Firefox will implement it too, with some differences (because some features of v3 are controversial), see https://blog.mozilla.org/addons/2021/05/27/manifest-v3-update/

It's available since Chromium 88, and will be available in Firefox at the end of 2021.
The manifest v2 (that we currently use) is still supported everywhere. It will eventually be deprecated and removed, but we have some time (I did not read any deadline yet)

Anyway, we will have to switch to it, maybe in 2022.

Base on what I read, and the fact that we are an offline extension with no permissions requested, I suppose the switch should be easy.
But it raises the question of backward compatibility : an extension with manifest v3 will probably not run on "old" versions of Firefox and Chromium that only support v2. If the switch is as easy as expected, and if we believe it's necessary, we might consider generating 2 versions of our extensions : one with a manifest v3, and one with a manifest v2 (with the same code)

[Jaifroid]

We should probably test v3, but stick with v2 for as long as it is allowed, in order to support older versions of browsers for as long as possible.

[Jaifroid]

There is now a timeline in Chrome for sunset of manifest v2: https://developer.chrome.com/docs/extensions/mv3/mv2-sunset/. To summarize, by June 2023 "All existing Manifest V2 items with visibility set to Public at that time will have their visibility changed to Unlisted", and by January 2024 "Chrome Web Store stops accepting updates to existing Manifest V2 extensions".

Mozilla is adopting manifest v3, but it seems it is going to keep many aspects of manifest v2 due to developer discontent with the limitations of the new manifest. I noted that their first Firefox Developer version of manifest v3 won't actually support Service Workers as the background script, so it looks like they are taking a staged approach: "In Firefox, we have decided to support Event Pages in MV3, and our developer preview will not include Service Workers (we’re continuing to work on supporting these for a future release)" - https://blog.mozilla.org/addons/2022/05/18/manifest-v3-in-firefox-recap-next-steps/.

I don't believe manifest v3 would have a negative effect on Kiwix JS, as it doesn't use APIs that are disappearing. In some ways it could be positive if the support for a Service Worker as the background script means that Firefox (if it adopts this) would be able to run Service Workers locally in the extension package. Of course, it would, as noted above, no longer support old browsers that do not have Service Workers.

It's not clear how we could continue to support v2 for old browsers. Perhaps the only support would be to provide a package that could be installed locally, since at least the Chrome and possibly the Edge stores won't list them from summer 2023.

[mossroy]

Providing a manifest v2 package for download on kiwix servers is probably a good approach, if it's not too complicated to support both v2 and v3

[Jaifroid]

As of April 2023, Firefox's implementation of manifest v3 doesn't support a Service Worker as the background script, whereas Chrome's (and Edge's) implementation ONLY support Service Worker. This means that it isn't possible currently to have an Extension manifest that supports both Chromium browsers and Firefox. The only solution currently touted (see here) is to have two different manifests and to swap between them when packaging the extensions in CI. It remains to be seen whether Service Workers are supported more generally in Mozilla's implementation of manifest v3.

The timeline for Chrome not accepting updates to manifest v2 extensions has now been put back to January 2024. So it will be important to have a Chromium-based v3 solution shortly for testing. I propose to stick with manifest v2 for Firefox until, as promised, Mozilla provides a version that supports Service Worker as the background script.

We should continue to support manifest v2 for older browsers via download of non-store extension file, so long as it's possible to sign such an extension.

[Jaifroid]

I've been experimenting in https://github.com/kiwix/kiwix-js/tree/Extension-manifest-v3, but after ironing out most errors, I'm left with the fact that we can't compile WASM or ASM modules without unsafe-eval and/or wasm-eval being defined in the Manifest's Content Security Policy. Unfortunately, neither value is allowed in manifest v3 unless the entire app is sandboxed. Sandboxing the entire app leads to our not being able to access the iframe (it appears). Touché...

[Jaifroid]

Ironically, I got it working (so far) only in jQuery mode.... In ServiceWorker mode, access to the iframe is currently blocked. Code is in https://github.com/kiwix/kiwix-js/tree/Extension-manifest-v3.

[Jaifroid]

Now working in ServiceWorker mode! The trick was that we cannot have two Service Workers controlling the chrome-extension domain, so it is necessary to run our service-worker as the backgroundscript (i.e. insert backgroundscript functions into our standard Service Worker). Code posted in #984.

Note that libzim (i.e. full-text search) is not yet working due to a blocked eval-like statement in the invoking code. Also note that inline scripts (unsafe-inline) don't work, just like in the v2 manifest. So #865 is still highly relevant.

[Jaifroid]

Libzim is now working in #984. I had to recompile the WASM with -s DYNAMIC_EXECUTION=0. Only the WASM is currently done, not ASM.

Incidentally, new javascript-libzim release now supports this scenario. See openzim/javascript-libzim#47 and https://github.com/openzim/javascript-libzim/releases/tag/v0.2.

[Jaifroid]

PR #984 pretty much ready for merging pending final tests.