1581852 - When installing an updated version from an add-on, the "allow in private browsing" checkbox in the notification can be unchecked even though permission was already given

Status: VERIFIED FIXED

(WebExtensions :: General, defect, P2)

Description

[:Gijs (he/him)]

STR:

1. install add-on
2. give private browsing permission
3. install a newer version of that add-on

ER:
doorhanger shows permission already checked

AR:
doorhanger shows permission unchecked; checking and unchecking has no effect on the extension's permissions.

Reported via twitter: https://twitter.com/lapcatsoftware/status/1173943810138738689

(I haven't tried to reproduce.)

Comment 1

[Shane Caraveo (:mixedpuppy)]

We should re-think the ux on this str

Comment 2

[Shane Caraveo (:mixedpuppy)]

Attachment: Bug 1581852 handle incognito checkbox for consecutive installs

Comment 3

[Shane Caraveo (:mixedpuppy)]

https://treeherder.mozilla.org/#/jobs?repo=try&revision=5902ce5c954472395784581a88e8ef1cb4ad15f2

Comment 4

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/efee2d5a8708
handle incognito checkbox for consecutive installs r=rpl

Comment 5

[Arthur Iakab [arthur_iakab]]

https://hg.mozilla.org/mozilla-central/rev/efee2d5a8708

Comment 6

[Alex Cornestean]

Hello,

Verified the fix using the latest Nightly (72.0a1/20191027212548) under Windows 10 Pro 64-bit and MacOS Catalina 10.15.

Installing a newer version of an add-on which was previously allowed to run in private windows will properly reflect this in the doorhanger i.e. the “Allow this extension to run in Private Windows” is checked in the doorhanger.

Note: Simply updating the add-on using the cogwheel menu will not display the doorhanger in question. For this, a newer version of the add-on must be sideloaded in order to produce a doorhanger.

Also checked the latest Beta (71.0b4/20191024095932) for comparison, where the issue is reproducible as per the STR from Comment 0.