Open Bug 1839129 Opened 1 year ago Updated 9 days ago

Offer controls for MV3 host permissions during install flow

Categories

(WebExtensions :: General, enhancement, P2)

Firefox 114
enhancement

Tracking

(Not tracked)

People

(Reporter: me+bz, Unassigned)

References

(Blocks 1 open bug)

Details

(Whiteboard: [addons-jira])

Steps to reproduce:

With manifest V3, host_permissions are marked as optional and there is not way to mark them not optional.

  • this should be documented
  • there should be a way to make this as non-optional (chrome allows it)
  • if really it's not possible, at least tell the user to enable the permission during installation

Hello,

Starting with Firefox 109 all host_permissions are considered optional so it appears what you are considering is an enhancement more than a bug. I will mark this accordingly.

Also, I do believe host_permissions are documented at https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/WebExtensions/manifest.json/host_permissions.

Type: defect → enhancement

Understood.

My extension is defunct if the host_permissions are not allowed, and Firefox is not offering the user to allow the optional permissions (at least when using the "Load Unpacked" mechanism).

Does that mean I need to check permissions programmatically when the addon loads? And if not allowed by user yet, what do I do? How can I prompt the user to allow the optional permission (I can't wait until they click on the toolbar button)?

What's the recommended approach?

@Luca

Would you be so kind and shed some light on the issue outlined in Comment 2? Thank you !

Flags: needinfo?(lgreco)

Hi Paul, thank you for the report. I responded to some of your specific questions below, but this area could definitely use some docs improvements. I submitted a PR with some more details based on your questions and suggestions: https://github.com/mdn/content/pull/27566

  • there should be a way to make this as non-optional (chrome allows it)

Currently in Safari and Firefox (in MV3), this is the default, while in Chromium-based browsers, similar behavior can be configured by the user, but is not yet the default. My understanding is that Google has plans to change that at some point in the future, but I can't really comment on their timelines.

Does that mean I need to check permissions programmatically when the addon loads? And if not allowed by user yet, what do I do? How can I prompt the user to allow the optional permission (I can't wait until they click on the toolbar button)?

What's the recommended approach?

Yes, that would be our recommendation. You should check for required permissions after installation using permissions.contains, and depending on your use case, possibly have an onboarding step that explains and request()s necessary permissions.

  • if really it's not possible, at least tell the user to enable the permission during installation

Yes, we're developing an update to the install flow for MV3, that will enable users to choose which host permissions to grant, and the default will be checked (meaning granted) for extensions which ask for a limited number of hosts (likely up to 6-10).

Flags: needinfo?(lgreco)

Yes, we're developing an update to the install flow for MV3, that will enable users to choose which host permissions to grant, and the default will be checked (meaning granted) for extensions which ask for a limited number of hosts (likely up to 6-10).

Forgot to add, even after we implement the new flow, and your extensions gets the default checked (granted) behavior, you should still account for the case when user decides to deny some of the requested permissions. This aspect will not change, we don't intend to remove ability for users to deny any of the requested permissions.

Severity: -- → N/A
Priority: -- → P2
Summary: MV3: User is not offered to enable optional permissions → Offer optional host permissions for MV3 during install flow
Whiteboard: [addons-jira]

Running browser.permissions.request() during add-on installation is not possible as it can only be run inside the handler for a user action, and the browser.runtime.onInstalled listener is not the case.

As a result, we cannot migrate our extension from MV2 to MV3 as some remote data need to be fetched and processed during add-on installation.

We propose that the host permissions should take the Chromium approach—enable by default (a warning about granted hosts can be shown during installation) and allows user revoking afterwards—to improve downward compatibility.

(In reply to Danny Lin from comment #6)

Running browser.permissions.request() during add-on installation is not possible as it can only be run inside the handler for a user action, and the browser.runtime.onInstalled listener is not the case.

From runtime.onInstalled you can open a tab with explanatory text to the user and a button to request a permission to be granted.

As a result, we cannot migrate our extension from MV2 to MV3 as some remote data need to be fetched and processed during add-on installation.

Do you control the backend? If yes, then your extension does not need host permissions if your server uses CORS to allow the extension access. If the information is not sensitive at all, the simplest would be to set Access-Control-Allow-Origin: * on the server's end. See the MDN article on CORS for more information: https://developer.mozilla.org/en-US/docs/Web/HTTP/CORS

Blocks: 1711787
Status: UNCONFIRMED → NEW
Ever confirmed: true

(In reply to Rob Wu [:robwu] from comment #7)

(In reply to Danny Lin from comment #6)

Running browser.permissions.request() during add-on installation is not possible as it can only be run inside the handler for a user action, and the browser.runtime.onInstalled listener is not the case.

From runtime.onInstalled you can open a tab with explanatory text to the user and a button to request a permission to be granted.

We are developing something like a malicious site blocker, which needs to load a blacklist from a default address on installation to work correctly.

Although this approach might be possible, it is much more annoying, and the extension may simply not work if the user missed the tab or forget to press the stupid request button, etc.

It used to simply work without any additional configuration on MV2, but now impossible on MV3. This is a poor regression for extension usability.

As a result, we cannot migrate our extension from MV2 to MV3 as some remote data need to be fetched and processed during add-on installation.

Do you control the backend? If yes, then your extension does not need host permissions if your server uses CORS to allow the extension access. If the information is not sensitive at all, the simplest would be to set Access-Control-Allow-Origin: * on the server's end. See the MDN article on CORS for more information: https://developer.mozilla.org/en-US/docs/Web/HTTP/CORS

Not always. It is already a common practice to provide source data using GitHub/GitLab or GitHub/GitLab pages, where CORS is not guaranteed to be set. Additionally we usually fetch data with Request.credentials = 'include' to maximally support any connections including potentially private connections, which always works with host permission but errors out without it as it's incompatible with CORS.

The key point is that in most cases the default host permissions are required for the core functionality of an extension, and thus it makes little sense to require an explicit user operation to make the extension function correctly.

The Chromium approach makes much more sense. Additionally, in this way it's fairly easy to implement "optional host permissions" by revoking some or all host permissions on an extension installation listener.

See Also: → 1863829

For reference, in Google Chrome MV3, there are both "host_permissions" and "optional_host_permissions".

For better cross-platform compatibility, "optional_host_permissions" should be implemented and "host_permissions" should work as in GC.

Duplicate of this bug: 1880600

We're going to grant host permissions by default to MV3 extensions (bug 1889402), at least until a better UX exists to enable host permissions at install time.

See Also: → 1889402
See Also: → 1893387
Summary: Offer optional host permissions for MV3 during install flow → Offer controls for MV3 host permissions during install flow
You need to log in before you can comment on or make changes to this bug.