build(extension): upgrading manifest v2 to v3

[sshanzel]

The changes made in the manifest were purely based on the guide in this document.

I have separated each commit to isolate the changes required from the document.

• Host permissions: 082d8f08f51ade0971d2a6a1b76e9385242d3fae
• Content security policy: 0da511e943ca1f824002e6e5717c29c892f25a41
• Action API unification: dc077ca860f5190c3a46b3e3442b964d5ed0130e
• WIP - web accessible resources: dc077ca860f5190c3a46b3e3442b964d5ed0130e
• Remotely hosted code: Not applicable
• Executing arbitrary strings: Not applicable
• Background service workers: Not applicable
• Modifying network requests: Not applicable

Sunset for deprecated APIs - we only had to change one API- chrome.extension.getURL() -> runtime.getURL()

We also had to switch the package we are using for web extension polyfills. The webextension-polyfill-ts has now been deprecated and we will have to switch to webextension-polyfill since the former was just a wrapper for TS implementations. There is now an official package to support the types through @types/webextension-polyfill

Note: based on firefox's timeline (Implementation timeline part) for migrating v3 they will start accepting submissions by early 2022 and they have not specified any future date. That means, this PR should be blocked until such time they allow the submissions. What about Chrome's decision for disallowing Manifest v2 apps?

After further reading, our app would still be allowed to be submitted even under manifest v2 based on Chrome's timeline for v3 up until the end of 2022.

Existing extensions can still be updated but new apps won't be accepted. With that, we should still be safe for uploading new versions but I have still created this PR in order for us to make the transition faster when the time comes.

[sshanzel]

Question for @idoshamun - the web-accessible-resources part has changed its structure and needs explicit value for which sites to allow access for the specified values (our index.html was specified). Though I understand based on our current settings, to allow any source but just wanted to check if we would still have the same configuration (by using a match pattern: "*://*/*").

[idoshamun]

Question for @idoshamun - the web-accessible-resources part has changed its structure and needs explicit value for which sites to allow access for the specified values (our index.html was specified). Though I understand based on our current settings, to allow any source but just wanted to check if we would still have the same configuration (by using a match pattern: "*://*/*").

web-accessible-resources are used for our authentication system. It allows us to redirect the user upon successful login. So I think index.html should be enough.

Thanks a lot for submitting such a detailed PR with all the relevant resources. Amazing! Before reviewing it, I'd like you to try this version locally using production settings. The migration to V3 is very delicate and potentially can break a lot of things. We need to be very thorough on this one.

A few potential pitfalls:

• Authentication system
• Visited sites mechanism
• Background script
• New tab
• Cookies

After you have enough confidence with this release we can go on and start the review. Again, thanks a lot for taking ownership of this critical task.

[idoshamun]

About the timeline, you are definitely right! I somehow missed that January is the deadline for new extensions. So once everything is validated and reviewed we should keep it as a draft until the time comes. Wow! Thanks for checking that.

[aUnicornDev]

After going through the code for any open Issues, I was reminded of the MV2 to MV3 transition that I had to do in my extension..

Jumped straight to the PR's to find this is being held as a draft for now.

Great PR @sshanzel !!