As part of Bug 1533150 we are going to hide the controls that allow a user to change the "extension private browsing access" for the extensions that are builtin, system or privileged add-ons (because they automatically get the "private browsing access" permission on every extension startup).

These builtin/system/privileged add-ons are going to have access to the private browsing windows (at least theoretically,
in some cases they may not even be doing anything in particular with them, as in the case of the "Firefox DevTools ADB Extension" mentioned in Bug 1533150) and so we are wondering if some special messaging may be required to better explain it to the user.

In particular these are some initial open questions about this:

• should we show some special text related to the private browsing access in the details page for these kind of extensions?
  (e.g. mention why that particular extension have access but it cannot be disallowed on PB windows by the user)

• should the "ALLOWED IN PRIVATE BROWSING WINDOW" badge be shown in the addons list view for them?

(In reply to Luca Greco [:rpl] from comment #0)

As part of Bug 1533150 we are going to hide the controls that allow a user to change the "extension private browsing access" for the extensions that are builtin, system or privileged add-ons (because they automatically get the "private browsing access" permission on every extension startup).

Built-ins/system addons don't show up in about:addons, probably good to write an STR for QE (though now I see mention of ADB below).

These builtin/system/privileged add-ons are going to have access to the private browsing windows (at least theoretically,
in some cases they may not even be doing anything in particular with them, as in the case of the "Firefox DevTools ADB Extension" mentioned in Bug 1533150) and so we are wondering if some special messaging may be required to better explain it to the user.

In particular these are some initial open questions about this:

• should we show some special text related to the private browsing access in the details page for these kind of extensions?
  (e.g. mention why that particular extension have access but it cannot be disallowed on PB windows by the user)

Some text explaining that the extensions private permission cannot be changed would be good. I'm unsure whether we should show, but disable, the controls, or just replace the controls with some text.

• should the "ALLOWED IN PRIVATE BROWSING WINDOW" badge be shown in the addons list view for them?

Absolutely. Showing an addon in the list that has access but not the badge is misleading.

I'm unclear on where systems add-ons show up. Based on this comment, "Built-ins/system addons don't show up in about:addons, probably good to write an STR for QE (though now I see mention of ADB below)." it looks like they DON'T show up in about:add-ons? If so, how can we add content clarifying their private browsing access?

System addons wont show up at all. But we have some addons that can be installed that are privileged and get private access automatically. Those do show up in about:addons. The specific example here is "Firefox DevTools ADB Extension".

In bug 1533150, we will leave the private badge on the extension list so users know it has that access, but in the detail view we are hiding the "run in private windows" option.

What we probably need to do is have some text in there that explains why it cannot be changed, which would replace the "Allow/Don't Allow" radio buttons. Then we'd remove the description underneath.

We should probably also do something for extensions that are not allowed to ever have access.

So in a detail view of the addon, you could have one of the following:

"Run in Private Windows": "O Allow O Don't Allow"

"Run in Private Windows": "This extension requires access to Private Windows, access cannot be changed."

"Run in Private Windows": "This extension is not allowed access to Private Windows, access cannot be changed."

Of course the text is too long, but hopefully illustrates what I'm suggesting.

The other issue here is, since it is new strings, it probably has to ride the train rather than be uplifted. :flod, is that correct?

Proposal:

For extensions that must run in Private Windows:

Requires Access to Private Windows [no toggle]
This extension has access to your online activities while private browsing. Learn more

For extensions that cannot run in Private Windows:

Not Allowed in Private Windows [no toggle]
This extension does not run while private browsing. Learn more

I think the SUMO article needs a new section about extensions that are not allowed/allowed by default. Do you agree? (https://support.mozilla.org/en-US/kb/extensions-private-browsing?as=u&utm_source=inproduct)

(In reply to Shane Caraveo (:mixedpuppy) from comment #4)

The other issue here is, since it is new strings, it probably has to ride the train rather than be uplifted. :flod, is that correct?

Which version is this feature tracking? Clearly it's not 64, like the bug is currently flagged :)

I'd be OK with uplifting if it has to target 67, and as long it happens quickly (within a week). If not, it has to ride the trains.

This shows all three options so you can see them, of course we'll only show the appropriate entry depending on conditions.

(In reply to Francesco Lodolo [:flod] from comment #6)

(In reply to Shane Caraveo (:mixedpuppy) from comment #4)
I'd be OK with uplifting if it has to target 67, and as long it happens quickly (within a week). If not, it has to ride the trains.

Other priorities delayed this, what would you say now if we can drop this in tomorrow?

(In reply to Shane Caraveo (:mixedpuppy) from comment #9)

Other priorities delayed this, what would you say now if we can drop this in tomorrow?

I honestly don't see how that can happen. The patch still needs review, landing in m-c, and beta approval from RelMan. Add the need for SUMO updates and the fact that tomorrow is b6 build day, this seems risky.

At this point it's a product call though, and you need to convince RelMan that the risk and timeline is acceptable. Personally I'd prefer this to ride the trains.

Updated screenshot

Comment on attachment 9053767 [details]
Bug 1536459 add messages for different private permission conditions

Beta/Release Uplift Approval Request

• Feature/Bug causing the regression: Bug 1380809
• User impact if declined: In two situations we do not indicate to the user why they cannot change the private window permission. This adds UI to about:addons that informs the user to that reason.
• Is this code covered by automated tests?: Yes
• Has the fix been verified in Nightly?: No
• Needs manual test from QE?: Yes
• If yes, steps to reproduce: Install any extension with incognito:now_allowed in the manifest
  install Firefox DevTools ADB Extension
  open about:addons, look at details for each

• not_allowed should show an explanation in place of the allow/don't allow toggle
• ADB should have an explation that it has private access and that it cannot be changed

see image in bug to see the text

• List of other uplifts needed: Bug 1538546
• Risk to taking this patch: Low
• Why is the change risky/not risky? (and alternatives if risky): Pretty minimal change but includes strings.
• String changes made/needed: YES

https://hg.mozilla.org/mozilla-central/rev/217849cb7750

Let's have QA verify on Nightly.

This issue is verified as fixed on Firefox 68.0a1 (20190328173141) under Win 7 64-bit and Mac OS X 10.14.1.

Please see the attached video.

This uplift request includes strings that landed in 68 and would be in beta 67, flod is that OK for you?

(In reply to Pascal Chevrel:pascalc from comment #18)

This uplift request includes strings that landed in 68 and would be in beta 67, flod is that OK for you?

Yes. I'm not thrilled about it, but I understand why we need it.

Comment on attachment 9053767 [details]
Bug 1536459 add messages for different private permission conditions

P1 for add-ons in incognito mode, verified by our QA on Nightly, green-light from our l10n-drivers. Uplift approved for 67 beta 7, thanks.

https://hg.mozilla.org/releases/mozilla-beta/rev/2a43c0f29c28

This issue is verified as fixed on Firefox 67.0b7 (20190331141835) under Win 7 64-bit and Mac OS X 10.14.1.

Please see the attached video.