MV3 host_permissions are always treated as optional
Categories
(WebExtensions :: Untriaged, defect)
Tracking
(Not tracked)
People
(Reporter: pospichal, Unassigned)
Details
Steps to reproduce:
Moved existing extension to MV3, moved host permissions under new key
"permissions": [
"nativeMessaging",
"activeTab",
"storage",
"cookies"
],
"host_permissions": [
"://.ica.cz/",
"://localhost/*"
],
Actual results:
I need to manually enable permission for each host in extension settings -> permissions, user is not asked during installation
Expected results:
This extension will not work without host permission. Host permissions should be treated as mandatory and user will be asked during installation. User then may change the setting manually.
|
||
Comment 1•3 years ago
|
||
The Bugbug bot thinks this bug should belong to the 'WebExtensions::Untriaged' component, and is moving the bug to that component. Please correct in case you think the bot is wrong.
|
||
Comment 2•3 years ago
•
|
||
(In reply to Ales Pospichal from comment #0)
I need to manually enable permission for each host in extension settings -> permissions, user is not asked during installation
This extension will not work without host permission. Host permissions should be treated as mandatory and user will be asked during installation. User then may change the setting manually.
Under MV3 this is intended behavior since bug 1745818, we treat all host permissions as optional, and opt-in by the user.
While we're still working on UX to allow users to more easily grant permissions extensions are asking for, extension can't treat any host permissions as "mandatory". They need to be prepared to detect (using permissions.contains) and handle the case when they're not (yet) granted necessary permissions, perhaps by asking for them via the premissions.request() API, if appropriate.
In your specific case, if your extension asks for a very limited set of host permissions (maybe up to five), we could even decide to ask for them during install, while giving the possibility for users to opt out (so you'll still need to detect/handle that), but as I said, those designs are not final.
Closing as wontfix.
This should probably be specified in bold in the host_permissions docs. I lost 1 day searching why it didn't work.
Description
•