Porting Chrome add-on -> Firefox: page permissions not granted by default?

Add-ons Development
#1

Background information: I am trying to port my a recently created Chrome Extension to Firefox. I am using manifest v3 for the Firefox version of my extension. I have had to make minimal changes to the Chrome manifest.json to get the extension to load in Firefox: .background.service_worker => .background.scripts, added .browser_specific_settings.gecko.id and .browser_specific_settings.gecko.strict_min_version, .options_page => .options_ui.page, add .options_ui.open_in_tab set to true. With these changes, I am able to load the extension XPI into Firefox Developer Edition with signature verification disabled.

However, when the extension is loaded, permission for content scripts on the web site it operates on is not granted by default. The user has to either click on the gear icon for the extension when on the relevant site and enable permissions, or go to the manage page for the extension and enable the permissions there.

This is different from Chrome, where the permissions are granted automatically when the user installs the extension.

Is this the behavior that end users of my extension on Firefox will see, or is this only occurring because I’m loading an unsigned extension so Firefox is being extra paranoid about it? Or is there something different I need to do in manifest.json on Firefox for permissions to be granted automatically?

I know that other extensions, e.g., Bitwarden, that I’ve installed from addons.mozilla.org do not have this problem; they don’t seem to need to be explicitly granted permission to run content scripts on a site. But I don’t know whether this is because they’re signed, or because they’re using manifest v2, or because there’s something different they’ve done in their manifest.json, etc.

My extension only operates on one web site and the user is pretty clearly granting permission for it to operate by installing the extension because it says quite clearly what site it is going to operate on, so it’s redundant and not user-friendly for them to have to then take additional steps to grant the permission so the extension will work. I’m hoping there’s a way to make that unnecessary that I just haven’t been able to identify yet.

1 Like
Welcome, Android extension devs!
#2

It’s because you are using a MV3 extension. MV2 get all their non-optional permissions by default.

From my understanding Chrome was planning to have the same behavior for MV3, but they either also abandoned that plan or haven’t gotten around to it.

#3

Thanks. Any idea whether I should expect for Firefox’s behavior to eventually revert to Chrome’s, or for Chrome’s to eventually mirror Firefox’s, or for them to continue to behave differently for the foreseeable future?

#4

I can’t speak for Chrome’s plans.

We’re developing an improved install flow for mv3 extensions, and if your extension only requests a few specific domains (so not <all_urls>) we’ll make it easier for users to grant that during install (likely checked by default).

Note that we don’t plan to revert any behavior in Firefox, so users could still decide not to grant those permissions (or may revoke them later), so your extension should still account for that, check and ask for any permissions it “needs” to function using the optional permissions api.

Hope that helps.

#5

Is there somewhere where the status and direction of this development can be followed? I did not succeed searching bugzilla for this?
… And is it expected to be ready for the next Firefox ESR (version 115)?

#6

The main issue with having host permission optional by default is that the permission API is not supported everywhere in Firefox.

For example, you can’t request for permission from the devtools (https://bugzilla.mozilla.org/show_bug.cgi?id=1796933)

#7

From my understanding Chrome was planning to have the same behavior for MV3, but they either also abandoned that plan or haven’t gotten around to it.

Chrome is taking a different approach to restricting host permissions; their plan is to implement a host permission limits across both Manifest V2 and V3. This plan was outlined in their Chrome Dev Summit 2020 talk. This is most recent thread I recall seeing about Chrome’s default host permission grants Default host permission grants during installation.

The main issue with having host permission optional by default is that the permission API is not supported everywhere in Firefox.

I believe you should be able to post a message from the DevTools panel to the extension’s background context and perform the permission request from there.

Simeon (dotproto)
Firefox WebExtensions DevRel

1 Like
#8

How would that work for the issue mentioned in the bug? (Where to put the notification)

Also, usually permission API is only ever able to be called in a user input event. Would doing a call to the background check work? I didn’t try but I’m sure it would (or should) fail, otherwise extension could request permissions without user input this way.

#9

Also, usually permission API is only ever able to be called in a user input event. Would doing a call to the background check work?

You’re right, I got my browser behaviors confused. Firefox does not forward the user input flag when passing a message between contexts. Support for that behavior seems to be covered by 1392624.

In that case I’d suggest showing a prompt in a developer tools panel that directs the user to the extension’s options page. In that page, you can prominently explain what permissions are necessary and why along side a “Request permission” button.

Alternatively, when the user opens your panel in developer tools, you could create a new popup window (panel messages background, background opens popup) that informs the user that some necessary permissions are missing, explain why they’re necessary, and display a “Request permissions” button in side that UI.

To be clear, neither of these are ideal solutions, but hopefully they’re workable until Firefox contributors are able to implement a more comprehensive fix.

Simeon (dotproto)
Firefox WebExtensions DevRel