Use manifest v3

[vitonsky]

Closes #412

Introduction

A chrome announced they will deprecate and disable extensions with manifest v2 soon. So we have to migrate to manifest v3.

Also, currently a custom translators runs in addon context, so its may use addon API that is potentially dangerous. We have to sandbox translators.

Manifest v3 status research

Currently manifest v3 is not production ready since

• it is partially supported by firefox and significantly limit a features for the addon. It does not support a sandbox and any way to call an eval function, does not support worker script and no have offscreen API. Additionally, a firefox makes a lot of permissions are optional, so it is not possible to request some permissions while install the addon, so as result user can't use translation for selected text, because it is necessary to click by addon icon to inject contentscript. Only one way to fix this problem is to create a special page that will explain the problem to user and will ask user to click on button that will request a permission, and open this page after install of addon that is bad UX. Here we may see how badly manifest v3 implemented in firefox - they decided that developers of firefox knows better which permissions for our addon are optional and which one is not.
• some old versions of firefox that may be still in use (like tor browser) may do not support a manifest v3 at all.
• chrome limit some API in manifest v3, to block an efficient ways to fight against ads.

So it is bad idea to migrate on manifest v3. However, we forced to migrate on v3 at least for chromium.

Solution

We decided to move on manifest v3 for a chrome and stay on v2 for another browsers.

We have to implement some glue code to make it work for all browsers, but currently this is the only way to keep all features enabled for all users.

Changes

• chromium manifest updated to v3
• code updated, to work with both manifest v2 and v3
• implemented sandboxing for environment to run a custom translators. Now we create an iframe for every custom translator and message it with postMessages. Iframe evaluates user provided code in secure context and return results with postMessages. A fetch function in sandboxed iframe is replaced to proxy that make request in parent frame (so it is possible to fetch any origin with any CSP) and then return Response back with postMessage.

side changes

• fixed messages in locale file src/_locales/gu/messages.json
• removed common chunks, since worker cannot to import common file

Testing

• firefox desktop
• firefox mobile
• chromium

[vitonsky]

TODO:

• get static info from custom translator and use it in translator class
• delete custom translators when it is no more necessary
• enable cache back for bergamot
• assign id for offscreen worker and react only on messages for the instance id, to allow run multiple workers
• move CSS media query to detect theme changes to an offscreen API
• fix bug in chromium when a custom translator cannot be selected right after addition
• remove debug prints
• simplify webpack config