Manifest 3 Permissions on Update

[Flo]

Our extension needs some changes in the manifest's permissions section when migrating from V2 to V3 (eg. move host permissions to "host_permissions" adding the "storage" permission to persist the service worker state).

Am i'm right that this means that the extension will be disabled after a users receives the update from Chrome Web Store and requires a user interaction to be reactivated? Or is there any special permission migration in place when moving from V2 to V3?

I'm a bit worried how big the hit on the user numbers will be because of the permission changes. Does anyone have experiences with this?

Thanks!

[Oliver Dunk]

Hi Flo,

Definitely appreciate this concern.

There isn't any special logic for MV3, but in general (this was the case in MV2 as well) your extension is only disabled if the permission changes have a non-trivial impact on what your extension can do. The actual logic for deciding that is complex, but at a high level what you need to check is that you're not adding a permission with a warning that the user hasn't seen before. You can see permissions with warnings here: https://developer.chrome.com/docs/extensions/mv3/permission_warnings/#permissions_with_warnings

Notably some permissions like alarms don't have warnings so you can safely add those without worry.

Given the complexity here and the fact that there are edge cases, I always advise testing. I'm also happy to answer questions if you want to share a before and after of your permissions.

We're investigating adding documentation/making that easier, but if you fancy getting in to the weeds, this article has most of what you need: https://developer.chrome.com/docs/extensions/mv3/linux_hosting/. From memory, you should be able to follow the same steps in a build of Chromium (https://download-chromium.appspot.com/) where there are slightly fewer restrictions on the types of distribution we allow (including on macOS). You'd basically want to make an extension with an update_url in the manifest, package it from chrome://extensions, manually install it, put a new version on the server and hit "update".

I think you can also do a similar test by just dragging packed extensions in to Chrome but because we disable them it's a lot harder to know if it's working properly or not. Do check with some permissions you know will generate warnings that this is working correctly if you rely on it.

Oliver Dunk | DevRel, Chrome Extensions | https://developer.chrome.com/ | London, GB

--
You received this message because you are subscribed to the Google Groups "Chromium Extensions" group.
To unsubscribe from this group and stop receiving emails from it, send an email to chromium-extens...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/chromium-extensions/fd410632-6d05-4040-9ca6-5ac8d68f6f38n%40chromium.org.

[Lu Xu]

Hi,

you can refer to this doc: https://developer.chrome.com/docs/extensions/mv3/permission_warnings/, as the doc shows, "storage" permission is not in the warning list, so adding the "storage" permission will not need user's consent.

As for moving to "host_permissions", if you are just migrating (without adding new hosts), I think it should be fine.

you can follow this part https://developer.chrome.com/docs/extensions/mv3/permission_warnings/#view_warnings to verify further

like, you package your MV2 crx, drag and drop to "chrome://extensions", some permission warning should prompt

then you bump your version, and package the MV3 crx, drag and drop again, you should see version updated, but no warning prompt.

and just FYI, the crx drag and drop can only verify the permissions, the extension is disabled by Chrome for security reasons.

[Flo]

Thanks a lot both of you. Good to know that the warning can be avoided if the new permissions are selected carefully. 

Do i understand correctly that the drag&drop testing method will no longer work because V2 extensions no longer be installed this way?

[Oliver Dunk]

Hi Flo,

I just checked and the drag and drop method does still seem to work. As Lu mentioned, just note that your extension will remain disabled, since we don't fully support installing extensions like that.

You also get slightly different UI, and won't be able to test things like the chrome.runtime.onInstalled event firing.

One option if you do want the extension to remain enabled is to use Chromium, which doesn't have the same restriction.

Oliver Dunk | DevRel, Chrome Extensions | https://developer.chrome.com/ | London, GB