Refactor how required permissions/origins are passed from Gecko to the embedder in `exportExtension()`
Categories
(GeckoView :: Extensions, task)
Tracking
(firefox128 fixed)
| Tracking | Status | |
|---|---|---|
| firefox128 | --- | fixed |
People
(Reporter: willdurand, Assigned: willdurand)
References
Details
(Whiteboard: [addons-jira])
Attachments
(1 file)
We're passing userPermissions to the embedder when exporting a gecko extension (using exportExtension()) but not always! For instance, we export different permissions when we react to an InstallPrompt event or when there is an add-on update. We're also filtering out some permissions because they aren't "promptable". This isn't very clear, and an Addon instance for an extension might have different permissions/origins depending on what is updating it.
I think we should always pass the userPermissions to the embedder, and explicitly pass the permissions/origins to the prompt delegate methods.
| Assignee | ||
Comment 1•1 year ago
|
||
Updated•1 year ago
|
| Assignee | ||
Updated•1 year ago
|
Updated•1 year ago
|
Comment 2•1 year ago
|
||
The proposed change here separates the concept of "what permissions to prompt during install" from the concept "what are the required permissions of this extension". This makes sense because the sets are not always the same. In particular, in a Manifest Version 3 extension, host permissions may be included in the install prompt, but they are fully optional. This was a recent change in bug 1839129 (before that bug, host permissions did not appear in the permission prompt in MV3, but they did in MV2).
I'm also noting that the Android-specific permission comparison logic only accounts for required permissions, not host permissions, at https://searchfox.org/mozilla-central/rev/e69f323af80c357d287fb6314745e75c62eab92a/mobile/android/modules/geckoview/GeckoViewWebExtension.sys.mjs#884-892
This means that if a MV3 extension adds a new "required" host permission, that there is no prompt for it. This behavior is consistent with how Firefox desktop behaves, and improving this flow is part of a follow-up bug, bug 1893232.
Comment 4•1 year ago
|
||
| bugherder | ||
Description
•