Closed Bug 1618500 Opened 4 years ago Closed 4 years ago

Moving permissions to optional permissions does not preserve them

Categories

(WebExtensions :: General, defect, P1)

75 Branch
defect

Tracking

(firefox-esr68 wontfix, firefox73 wontfix, firefox74 wontfix, firefox75 fixed)

RESOLVED FIXED
mozilla75
Tracking Status
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

Tested with Nightly 75.0a1 (2020-02-26) (64-bit)

Assignee: nobody → mixedpuppy
Priority: -- → P1

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.

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.

Status: UNCONFIRMED → NEW
Ever confirmed: true
Has STR: --- → yes
Attachment #9129669 - Attachment description: Bug 1618500 update optional addon permissions when migrated from required permissions → Bug 1618500 properly migrate addon permissions when removing or moving to optional
Attachment #9129669 - Attachment description: Bug 1618500 properly migrate addon permissions when removing or moving to optional → Bug 1618500 handle permissions and preferences changes on addon update
Pushed by scaraveo@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/cfca069fc4b2
handle permissions and preferences changes on addon update r=aswan
Status: NEW → RESOLVED
Closed: 4 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla75
Depends on: 1622117
Regressions: 1630694

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.»

Regressions: 1636177
Regressions: 1654812
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: