Evaluate what to show in about:addons for add-ons with locked "private browsing access" mode and add-ons set to "not_allowed"

VERIFIED FIXED in Firefox 67

Status

()

defect
P1
normal
VERIFIED FIXED
5 months ago
4 months ago

People

(Reporter: rpl, Assigned: mixedpuppy)

Tracking

67 Branch
mozilla68
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(firefox-esr60 unaffected, firefox66 unaffected, firefox67 verified, firefox68 verified)

Details

Attachments

(4 attachments, 1 obsolete attachment)

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?

Depends on: 1533150

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

Flags: needinfo?(mwalkington)
Flags: needinfo?(emanuela)

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?

Flags: needinfo?(mwalkington) → needinfo?(mixedpuppy)

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.

Flags: needinfo?(mixedpuppy) → needinfo?(mwalkington)

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?

Flags: needinfo?(francesco.lodolo)

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)

Flags: needinfo?(mwalkington) → needinfo?(mixedpuppy)

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

Flags: needinfo?(francesco.lodolo)
Flags: needinfo?(mixedpuppy)
Version: 64 Branch → 67 Branch
Priority: -- → P1
Assignee: nobody → mixedpuppy

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

Attachment #9053756 - Flags: ui-review?(mwalkington)

(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?

Flags: needinfo?(francesco.lodolo)

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

Flags: needinfo?(francesco.lodolo)
Summary: Evaluate what to show in about:addons for addons with locked "private browsing access" mode → Evaluate what to show in about:addons for add-ons with locked "private browsing access" mode and add-ons set to "not_allowed"
Depends on: 1538546
Comment on attachment 9053756 [details]
Screen Shot 2019-03-26 at 4.09.15 PM.png

For #2 and #3 instances, we do not need the line "Run in Private Windows." The headers can just be, respectably, "Requires Access to Private Windows" and "Not Allowed in Private Windows." Otherwise it looks good.
Attachment #9053756 - Flags: ui-review?(mwalkington) → ui-review+

Updated screenshot

Attachment #9053756 - Attachment is obsolete: true
Pushed by scaraveo@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/217849cb7750
add messages for different private permission conditions r=flod,aswan

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
Attachment #9053767 - Flags: approval-mozilla-beta?
Flags: qe-verify?
Status: NEW → RESOLVED
Closed: 5 months ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla68

Let's have QA verify on Nightly.

Flags: qe-verify? → qe-verify+
QA Whiteboard: [qa-triaged]
Posted image Bug1536459.gif

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.

Status: RESOLVED → VERIFIED
Flags: qe-verify+

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

Flags: needinfo?(francesco.lodolo)

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

Flags: needinfo?(francesco.lodolo)

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.

Attachment #9053767 - Flags: approval-mozilla-beta? → approval-mozilla-beta+
Posted image Bug1536459Beta.gif

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.

Flags: needinfo?(emanuela)
You need to log in before you can comment on or make changes to this bug.