Closed Bug 1556655 Opened 5 months ago Closed Last month

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

Categories

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

69 Branch
defect

Tracking

()

RESOLVED FIXED
mozilla71
Tracking Status
firefox-esr60 --- unaffected
firefox-esr68 --- unaffected
firefox67 --- unaffected
firefox67.0.1 --- unaffected
firefox68 --- unaffected
firefox69 --- disabled
firefox70 --- disabled
firefox71 --- fixed

People

(Reporter: ke5trel, Assigned: tjr)

References

(Depends on 1 open bug, Blocks 2 open bugs, Regression)

Details

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

Attachments

(1 file)

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: Last month
Resolution: --- → FIXED
Target Milestone: --- → mozilla71

What's the status for Beta70 here?

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