Extensions using content scripts without any user action wont work anymore in MV3

Lets assume we have an extension that simply sets the background color of each page to black. All it needs is the host permission <all_urls> and a content script/style sheet that gets injected in every page. In MV2 the user will be prompted on install time if he wants to grant the extension the permission to access every page. If the user accepts, the extensions works everywhere as expected right out of the box.

However in MV3 host permissions are optional, this means the user wont be prompted on install time. Instead the extension needs to explicitly ask for the host permission. That’s where the problem arises. permissions.request() can only be called inside a handler for a user action. This simple add-on doesn’t have any page action, context menu entry or the like. Therefore it cannot call for the necessary permission which makes the extension seem to be completely broken to the user.

Of course the user could go to the add-ons permission page and grant the permission there, but I think everyone agrees that this is not a viable option. Users expect a program to run out of the box with minimal permissions. For some extensions the host permission is the minimal set of required permission.

I don’t understand why the user cannot be asked on install time if he wants to accept the host permission or not. If the user declines the extension could still be installed, but without the host permission. At this point the user actively declined a permission and would therefore expect that something might not work correctly.

The only option I currently see is to add and open an extension page on install which contains a button that the user first needs to press, which then in return prompts if the user wants to grant the requested permission. This seems cumbersome for both, the programmer and the user.

Can someone please explain how such extensions (e.g. mouse gesture extensions) are supposed to work with MV3? Thanks in advance.

1 Like

We’re adding UI to make it easier for users to understand what host permissions an extension needs/has, and to grant/revoke them:

  1. Ability to grant host permissions from the browser action context menu since bug 1769793 landed in Nightly a few days ago.
  2. Ability to run content scripts for the current site when clicking the the browser action, bug 1774641 to land this week in Nightly.

We’re also working on similar affordances for extensions which don’t have a browser action button, and also on ability for users to choose to grant permissions at install time (though they will explicitly need to opt-in for extensions that list <all_urls>).

All that being said, even after we provide all that new UI, users might choose to not grant host permissions your extension is asking for, so developers still need to account for that. You can use the existing APIs to detect (permissions.contains or permissions.getAll) and request (permissions.request) permissions, as is appropriate for your extensions.

Thanks for your reply. I was aware of the first 2 bugs you’ve mentioned, but they don’t really solve the problem for the type of add-on I described.

That sounds interesting, do you have more details on that, or is there any bugzilla ticket that devs can follow?

Not yet, we’re still working on designs with UX, but we should have some bugs in the next few weeks, which will block bug 1711787.

1 Like

Since Chrome/Edge/Safari have a head start on this, there must be suggestions on relevant developer sites for this. Which patterns are work best, I have no idea.

After my initial attempt to get some MV3 experience with one of my extensions, I slowly start to realize your plans when it comes to handling host-permissions…

So if I have an extension specifically constructed for flickr.com, the user cannot grant the host permission (solely) for flickr.com already at install time. But will have to do it on next visit to flickr.com? Sorry, but that sounds kind of lame to me.

Does Google do the same?

1 Like

I think they got inspired by Safari where from the very beginning they don’t allow newly installed addons to run on specified pages until user allows it, and user can refuse it or allow it only temporary. This is how it looks like:

So maybe as a part of the on-boarding, you may need to open the "flickr.com" page to trigger the permission dialog… But who knows how they implement it in the end.