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

Status: VERIFIED FIXED

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

Description

[Kestrel]

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.

Comment 1

[Daniel Veditz [:dveditz]]

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.

Comment 2

[Tom Ritter [:tjr]]

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

Comment 3

[Tom Ritter [:tjr]]

Attachment: Bug 1556655 - Add addons.cdn.mozilla.net to the list of separatedMozillaDomains r?ulfr,aswan

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.

Comment 4

[Tom Ritter [:tjr]]

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

Comment 5

[Kestrel]

Currently it's working.

Fix window:
https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=9b4358c2ea5fb38b7d8208be96efcdd1fc7e77dd&tochange=0fc603b37e654a5fb4205c8494c95d3102e604d9

Fixed by Bug 1557073.

Comment 6

[BugBot [:suhaib / :marco/ :calixte]]

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

For more information, please visit auto_nag documentation.

Comment 7

[BugBot [:suhaib / :marco/ :calixte]]

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.

Comment 8

[Tom Ritter [:tjr]]

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

Comment 9

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/530704adfcdb
Add addons.cdn.mozilla.net to the list of separatedMozillaDomains r=ulfr,kmag

Comment 10

[Noemi Erli[:noemi_erli]]

https://hg.mozilla.org/mozilla-central/rev/530704adfcdb

Comment 11

[Ryan VanderMeulen [:RyanVM]]

What's the status for Beta70 here?

Comment 12

[Miruna Curtean]

Attachment: Add to Firefox not removed.gif

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?

Comment 13

[Tom Ritter [:tjr]]

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

Comment 14

[Miruna Curtean]

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