Closed Bug 1556655 Opened 1 year ago Closed 1 year ago

Installing extension from AMO fails with privacy.resistFingerprinting.block_mozAddonManager=true

Categories

(Core :: DOM: Security, defect, P3)

69 Branch
defect

Tracking

()

VERIFIED FIXED
mozilla71
Tracking Status
firefox-esr60 --- unaffected
firefox-esr68 --- unaffected
firefox67 --- unaffected
firefox67.0.1 --- unaffected
firefox68 --- unaffected
firefox69 --- disabled
firefox70 --- disabled
firefox71 --- verified
firefox72 --- verified

People

(Reporter: ke5trel, Assigned: tjr)

References

(Blocks 1 open bug, Regression)

Details

(Keywords: regression, Whiteboard: [fingerprinting][domsecurity-active][no-nag])

Attachments

(2 files)

STR:

  1. Set privacy.resistFingerprinting.block_mozAddonManager=true
  2. Go to AMO and install an extension.

A blank white page appears with no popup prompt to install extension.

Browser console error:

NS_NOINTERFACE: Component returned failure code: 0x80004002 (NS_NOINTERFACE) [nsIInterfaceRequestor.getInterface] amContentHandler.jsm:40

Regression window:
https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=0553541318c4d5b7aba2a9b195470db9dc5c782e&tochange=a707cab2f14d5a33998bdaa3fbbbdc19e5317af1

Regressed by Bug 1539595.

Flags: needinfo?(tom)

I haven't read the details in bug 1539595, but AMO uses the mozAddonManager to install things so if we made a pref to block it then I'm not surprised AMO doesn't work when you use that pref. Maybe the pref was for special cases so that AMO would work in the right contexts.

Surprisingly AMO did work even when the API was blocked. I didn't know that; but thinking about it more critically I'm not surprised (otherwise Tor Browser users wouldn't be able to install extensions, and we know they can). I'm currently updating and building to debug what's going on here and why it a) worked before and b) is now broken

When mozAddonManager isn't available, AMO installs extensions through a different code
path that involves downloading the XPI from addons.cdn.mozilla.net and routing through
amContentHandler.jsm

That code breaks when addons.cdn.mozilla.net is in a separate process. So we put it into
the privileged mozilla web content process. Admittedly this isn't used in 99.99% of cases.

As an update for those following on Bugzilla and not Phab: this may get unbroke when we improve the solution from Bug 1539595 but if it doesn't, we still have a solution (the attached patch).

Whiteboard: [fingerprinting] → [fingerprinting][domsecurity-active]

The priority flag is not set for this bug.
:ckerschb, could you have a look please?

For more information, please visit auto_nag documentation.

Flags: needinfo?(ckerschb)
Flags: needinfo?(ckerschb)
Priority: -- → P3

There's a r+ patch which didn't land and no activity in this bug for 2 weeks.
:tjr, could you have a look please?
For more information, please visit auto_nag documentation.

Flags: needinfo?(tom)
Flags: needinfo?(tom)
Whiteboard: [fingerprinting][domsecurity-active] → [fingerprinting][domsecurity-active][no-nag]

Going to land this for now, and when Bug 1574372 is fixed we can back it out.

Pushed by tritter@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/530704adfcdb
Add addons.cdn.mozilla.net to the list of separatedMozillaDomains r=ulfr,kmag
Status: NEW → RESOLVED
Closed: 1 year ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla71

What's the status for Beta70 here?

Flags: needinfo?(tom)

I've tested this on Windows PRO 10 64-bit, Ubuntu 18.04.3 LTS and macOS 10.15 Catalina on Firefox Beta 71.0b7 (20191104135555) and Nightly 72.0a1 (20191105095755) and after adding and setting the privacy.resistFingerprinting.block_mozAddonManager=true the browser was restarted and various recommended add-ons from AMO were successfully installed.
However, whenever installing an extensions while the pref is set to true, the "Add to Firefox" button is still available. This occurs on Release as well, so maybe it's a known behavior. Are there any other prefs that have to be setup in order for the "Remove" button to be displayed after the extensions has been installed?
Or is it a known issue?

Flags: needinfo?(tom)

(In reply to Miruna Curtean from comment #12)

However, whenever installing an extensions while the pref is set to true, the "Add to Firefox" button is still available. This occurs on Release as well, so maybe it's a known behavior. Are there any other prefs that have to be setup in order for the "Remove" button to be displayed after the extensions has been installed?
Or is it a known issue?

Thanks for this. You are correct that this is a known issue. I filed https://github.com/mozilla/addons/issues/1127 to get it on file.

Flags: needinfo?(tom)

Thank you for the confirmation, Tom. Considering that, I am setting this bug as Verified fixed on Windows PRO 10 64-bit, Ubuntu 18.04.3 LTS and macOS 10.15 Catalina on Firefox Beta 71.0b7 (20191104135555) and Nightly 72.0a1 (20191105095755).

Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.