[ext] Manifest V3 support

[sigmike]

Chrome will eventually stop supporting manifest V2, so we should prepare support for manifest V3.

Some references:

• https://developer.chrome.com/blog/resuming-the-transition-to-mv3?hl=en ("we highly recommend completing migration to Manifest V3 before June 2024")
• https://developer.chrome.com/docs/extensions/develop/migrate/what-is-mv3
• https://developer.chrome.com/docs/extensions/develop/migrate/checklist?hl=en
• https://extensionworkshop.com/documentation/develop/manifest-v3-migration-guide/

[sigmike]

@GresilleSiffle @amatissart @lfaucon Firefox has supported manifest V3 since version 109, released in January 2023. Do we want to keep a manifest V2 version to maintain compatibility with Firefox versions < 109? Or should we fully migrate to V3? It's not very difficult to support both with the new system that generates the manifest, but it does add a bit of complexity to handle both cases.

Do you know if we have any users using an old Firefox?

[GresilleSiffle]

Hello @sigmike

Thank for all those references. We are going to check in our analytics what % of users use Firefox < 109.

[amatissart]

@sigmike If the support is good enough on Firefox too, I think it would reasonable to support manifest v3 only.
There is a small residue of Firefox 108 in the logs, but that seems to be specific to Android where the extension is not currently available anyway.

[sigmike]

@GresilleSiffle @amatissart Ok thank you.

So I've done some more testing and we can't really have a manifest V3 that works well on all browsers (yet?). To sum up, it doesn't work well on Firefox, but works well on Chrome.

So I suggest we start building 2 versions of the extension: one for Firefox (with manifest V2 for now, and maybe V3 later) and one for Chrome-based browsers (with manifest V3). And maybe one day both extensions will be identical, but we might still want or need browser specific features.

Or we can just ignore manifest V3 for now, and try again when it's about to become mandatory.

The details of the problems:

1. Background: Chrome requires a service_worker for the background key, and Firefox doesn't support it (yet, probably). We can use both script and service_worker at the same time for a manifest that works on both, but it's only supported from Chrome 121 which was released in January 2024. Reference.

2. Content scripts: On Firefox, declaring host permissions and matches for content scripts is not enough to automatically load them. It requires the user to explicitly allow each website by right-clicking on the extension icon. They say it's required by manifest V3 but Chrome doesn't require that. It seems very bad from an UX perspective. Source, a Reddit question about that.

3. CORS: On Firefox, requests made by the extension now have cross-origin checks. And the origin seems to be the extension id. I'm not sure how we can deal with that. Question on stackoverflow, MDN doc mentioning the value of origin.

Finally, as for the response header change we make, I think we can just remove it. Since 1accca6 the backend adds a Content-Security-Policy header that overrides the X-Frame-Options header and allows frames from youtube. So this header change would only be needed for browser that do not support the frame-ancestors in Content-Security-Policy, so Chrome < 40 (2015) and Firefox < 58 (2018). I've tested on both Firefox and Chrome and the frame is indeed allowed if the header change is removed.

[GresilleSiffle]

Regarding the opt-in permissions on Firefox. We may need to prompt the user with the permissions API.