Can't set "Firefox DevTools ADB Extension" to not allowed in private windows

VERIFIED FIXED in Firefox 67

Status

defect
P1
normal
VERIFIED FIXED
4 months ago
4 months ago

People

(Reporter: haik, Assigned: rpl)

Tracking

(Blocks 1 bug)

unspecified
mozilla68
Dependency tree / graph

Firefox Tracking Flags

(firefox67 verified, firefox68 verified)

Details

Attachments

(4 attachments)

On Mac Nightly, in about:addons for the "Firefox DevTools ADB Extension" extension, setting "Don't Allow" for Run in Private Windows does not work. When clicking the Don't Allow radio button, the selection jumps back to Allow.

67.0a1 (2019-03-06) (64-bit)
Built from https://hg.mozilla.org/mozilla-central/rev/3e0cf2f77f07b258e8911ab5fd71a378c46fa1ec

See screenshot.

The "Firefox DevTools ADB Extension" is a privileged extension (in the sense that it is signed as a Mozilla Internal Extension) and, as a privileged extension, it gets the permission to access PB windows by default on its startup, and that is very likely the reason why setting "Don't Allow" on it is quickly reverted to "Allow".

Unlike other system addons it is not built-in (but installed when the DevTools internals are going to need it to reach a remote android target) and it is not marked as hidden in the manifest.json.

This extension is actually used only to provides the ADB binaries, it doesn't contain any extension page or experiment APIs, and so the option to "Allow/Don't Allow PB windows access" wouldn't really do anything useful on this extension, and so allowing it doesn't seems to make a lot of sense for this extension.

The following are a couple of strategies that we may use to avoid this unexpected behavior:

  • hiding the "Allow/Don't Allow PB windows access" radio buttons for any privileged extension signed with the Mozilla internal key (but this may be too much, in some cases it may be reasonable to allow the user to toggle this permission on an extension signed with the Mozilla internal key)

  • or adding support for an additional manifest key, only available to Mozilla Internal Extensions (similarly to the hidden manifest property), that would allow an internal extension to ask Firefox to hide the "Allow/Don't Allow PB windows access" radio buttons and the "incognito badge", to be used for internal extensions that are not hidden in about:addons when we know that toggling the "PB windows access" doesn't make any sense (as in this case) or when "denying the PB windows access" would completely break the internal extension

Assignee: nobody → mixedpuppy
Priority: -- → P1
Assignee: mixedpuppy → lgreco
Status: NEW → ASSIGNED
Blocks: 1536459

Lets uplift this one when ready.

Duplicate of this bug: 1538025
Duplicate of this bug: 1538084

Thanks for working on this (and sorry about the dupes!)

If the ADB Extension is the only privileged extension displayed in about:addons, we can mark it as hidden. Let us know if that would make things easier for you. We have https://github.com/mozilla/devtools-adb-extension/issues/8 logged on GitHub for this.

Flags: needinfo?(lgreco)
Pushed by luca.greco@alcacoop.it:
https://hg.mozilla.org/integration/autoland/rev/935c4b228e48
Hide 'Run in Private Windows' controls from about:addons for extensions allowed automatically on every extension startup. r=aswan,mixedpuppy

(In reply to Julian Descottes [:jdescottes] from comment #6)

Thanks for working on this (and sorry about the dupes!)

no worries at all

If the ADB Extension is the only privileged extension displayed in about:addons, we can mark it as hidden. Let us know if that would make things easier for you. We have https://github.com/mozilla/devtools-adb-extension/issues/8 logged on GitHub for this.

If the users have another way to uninstall the extension (e.g. from the WebIDE now and the new about:debugging once enabled by default?) then marking the ADB extension as hidden would probably make sense.

(Nevertheless, we are still going to proceed with fixing the general issue with the attached patch because there may be other privileged addons that may still want to appear in about:addons, to allow the users to disable/enable/uninstall it).

Flags: needinfo?(lgreco)
Status: ASSIGNED → RESOLVED
Closed: 4 months ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla68

Comment on attachment 9051267 [details]
Bug 1533150 - Hide 'Run in Private Windows' controls from about:addons for extensions allowed automatically on every extension startup. r?aswan!,mixedpuppy

Beta/Release Uplift Approval Request

  • Feature/Bug causing the regression: Bug 1380809
  • User impact if declined: "Firefox DevTools ADB Extension" has private window permission flipping when it should not.
  • Is this code covered by automated tests?: Yes
  • Has the fix been verified in Nightly?: Yes
  • Needs manual test from QE?: Yes
  • If yes, steps to reproduce: Install ADB
    Check in about:addons
  • in list it will have purple private badge
  • in details it will not have the toggle to change the private windows state
  • List of other uplifts needed: None
  • Risk to taking this patch: Low
  • Why is the change risky/not risky? (and alternatives if risky): minimal change with followups in bug 1538546
  • String changes made/needed: none
Attachment #9051267 - Flags: approval-mozilla-beta?
Flags: qe-verify?
Posted image Bug1533150.gif

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

Please see the attached video.

Status: RESOLVED → VERIFIED
Flags: qe-verify?

Comment on attachment 9051267 [details]
Bug 1533150 - Hide 'Run in Private Windows' controls from about:addons for extensions allowed automatically on every extension startup. r?aswan!,mixedpuppy

Low risk patch with tests, verified in Nightly by QA, uplift approved for 67 beta 6, thanks.

Attachment #9051267 - Flags: approval-mozilla-beta? → approval-mozilla-beta+
Posted image Bug1533150Beta.gif

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

Please see the attached video.

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