Moving permissions to optional permissions does not preserve them
Categories
(WebExtensions :: General, defect, P1)
Tracking
(firefox-esr68 wontfix, firefox73 wontfix, firefox74 wontfix, firefox75 fixed)
People
(Reporter: mozilla+bugzilla, Assigned: mixedpuppy)
References
(Blocks 1 open bug)
Details
Attachments
(1 file)
Actual behavior
Changing WebExtension manifest for existing users/installations from
"permissions": [
"<all_urls>",
"proxy",
"webRequest",
"webRequestBlocking"
],
to
"permissions": [
"proxy"
],
"optional_permissions": [
"<all_urls>",
"webRequest",
"webRequestBlocking"
],
looses previously granted permissions that are moved to optional permissions.
Expected behavior
Permissions should be preserved once granted, even when moved to be optional
Steps to reproduce
- Install
permissions-0.2-fx.xpi
from https://github.com/stoically/test-webext-permissions-bug/releases/tag/v0.2 - Inspect the background console for the installed "Permissions" extension to see result of
permissions.getAll
- Use Add-ons Manager to "Check for updates"
- Wait until "Permissions" updates to v0.3 (https://github.com/stoically/test-webext-permissions-bug/releases/tag/v0.3)
- Inspect the background console for the updated "Permissions" extension to see result of
permissions.getAll
Tested with Nightly 75.0a1 (2020-02-26) (64-bit)
Assignee | ||
Updated•4 years ago
|
Assignee | ||
Comment 1•4 years ago
|
||
If an addon is updated and moves permissions from required to optional, we
want to retain the previously granted permission so the extension does not have to
request the permission from the user again.
Assignee | ||
Comment 2•4 years ago
|
||
https://treeherder.mozilla.org/#/jobs?repo=try&revision=6b11f7506b87c8f0640e00d3cbcc6ca2b0b25d97
Comment 3•4 years ago
|
||
Hello,
I have managed to successfully reproduce the issue using the provided STR on the latest Nightly (75.0a1/20200301213924), Beta (74.0b9/20200227210932), Release (73.0.1/20200217142647) and ESR (68.5.0esr/20200206211857) under Windows 10 Pro 64-bit, MacOS Catalina 10.15 and Ubuntu 16.04 LTS.
Prior to updating the add-on, all 4 permissions ("<all_urls>", "proxy", “webRequest", "webRequestBlocking") are displayed in the debug console. After the add-on update, only the “proxy” permission is displayed in the console, confirming the bug.
Regarding a possible regression window, I’ve run multiple regression ranges (from FX65 up to current versions and from late 2018 up to the current date) and it seems that all versions starting from 68 onward are affected by this issue. Versions prior to 68 could not be properly tested due to the add-on being incompatible with the browser. Considering this, it seems that the bug might not be a regression.
Updated•4 years ago
|
Updated•4 years ago
|
Assignee | ||
Comment 4•4 years ago
|
||
https://treeherder.mozilla.org/#/jobs?repo=try&revision=a326ab67fab13fd67c15d9bf151fa07f6f9507bd
Assignee | ||
Comment 5•4 years ago
|
||
https://treeherder.mozilla.org/#/jobs?repo=try&revision=269cdda336491018ce23800cbe225c467804a1e4
Assignee | ||
Comment 6•4 years ago
|
||
https://treeherder.mozilla.org/#/jobs?repo=try&revision=f2609e904869ee24dc4caf822fe6bf49b50b3220
Updated•4 years ago
|
Pushed by scaraveo@mozilla.com: https://hg.mozilla.org/integration/autoland/rev/cfca069fc4b2 handle permissions and preferences changes on addon update r=aswan
Comment 8•4 years ago
|
||
bugherder |
Updated•4 years ago
|
I suppose this could be made explicit in the documentation? I would have missed this if I wasn’t for the «WebExtensions API updates» newsletter.
In my case, I wanted to change contextualIdentity
(and cookie
) from permissions
to optional_permissions
, but didn’t because I feared it would be disabled at first and my users would lose their tabs opened in a container.
Besides, if it’s stated clearly in the documentation, it may encourage developers to change some of their permissions to make them optional, without the fear of breaking what’s already working for their existing users.
I’m writing this here in part because maybe it should be precised in this tutorial page.
Otherwise, for MDN pages, I’d go «You can make a permission optional by moving it from the permissions
to the optional_permissions
key, and it won’t revoke the permission for existing users of your extension.»
Description
•