Manifest V3 megathread

[WorldLanguages]

At one point Chrome will start making new users have host permissions "only when the user clicks the extension icon". Keep in mind this does not depend on whether we update to manifest 3, this will also affect manifest v2 extensions after the release of manifest v3.
We might want to provide users a way to use SA dynamically (loading addons when clicking the extension), even tho this would be pretty limited, and no addons could do stuff like accessing the VM.
At one point, we might need to have two different branches for Chrome and Firefox, in case Chrome does not allow us to upload V2 manifests anymore, and Firefox does not yet support V3.
Anything else related to this should be commented here.

[GrahamSH-LLK]

Yikes! Chrome is really ruining extensions.

[jeffalo]

yo thats kinda insane, i really hope they dont actually go through with this.

edit: from what i can tell, users can choose to allow host permission automatically https://developer.chrome.com/docs/extensions/mv2/runtime_host_permissions/#access-on-all-sites

[TheColaber]

Ah! Losing vm wouldn't be good! We'd also lose many addons!

[mxmou]

We would probably need to tell users to change the site access permissions so they can still use those addons.

[WorldLanguages]

I wasn't clear enough maybe - access to the VM would only be lost if the user didn't grant us permission to automatically inject scripts to scratch.mit.edu automatically, without them needing to click the extension icon. Right now that permission is granted by default, and can be revoked by right clicking the icon in a scratch.mit.edu page, and selecting "this can read and change site data... when you click the extension". But aparently, in the future, that will be the default, so we should either

1. Ask the user for permission right after install (that's what would happen right now if we didn't make any changes)
2. Allow users to run addons only when the icon is clicked - but any addons that need access to the VM wouldn't able to get a reference to it (at least, with our current way of doing it)

[TheColaber]

I can't believe we'd need to go through all that trouble just to run addons and access the VM before it's too late.

[Bloctans]

One year later, They are now forcing it.

[Hans5958]

From #5162 (sent October 2022, edited Feb 2023, aware the outdated):

News on manifest V3 (MV3)

New blog post by Chrome team, 1 week ago: https://developer.chrome.com/blog/more-mv2-transition/

Here's a summary:

EDIT: these dates are outdated. Chrome keeps changing them.

If we don't update to MV3 by ... the consequences will be:

• January 2023: we might lose the "featured" badge, but we may continue to push MV2 updates.
• June 2023: the extension must be "unlisted", a portion of Chrome stable users will not be able to use MV2, but we may continue to push MV2 updates.
• January 2024: MV2 extensions are removed from the Chrome Web Store. We must push an MV3 update or disappear from the store.

Of course, we will update to MV3 before June 2023. But, we previously thought Chrome would stop supporting MV2 entirely by January 2023, and that's not the case. The "featured" tag is the only incentive until mid-2023.

By the way, it's possible that no single manifest.json file will be accepted by both Chrome and Firefox at the same time. This would mean we would need to add a build step to the extension.
We currently do ship different manifest.json files to each browser store, but we use the same one for development. It looks like there will be no way to keep that situation on MV3, because Chrome expects background.service_worker to be defined (as long as the extension wants to have background code, and we do), and Firefox throws if it finds that property, because it decided to support "event pages" instead.
Supporting SWs and "event pages" at the same time isn't an issue, because SW code will work perfectly fine on an event page, but it would require two different manifest.json files for development, changing our current workflow.
I would need to research more deeply into this to have a final say, but it's likely a build step will be necessary. Testing a PR won't be as easy as downloading the zipball for that branch, and uploading it into the browser extensions page. Running a node.js command would be required.
Edit: see w3c/webextensions#282