1083637 - Blocking installs for marketplace.firefox.com doesn't work until preferences has been opened

Status: RESOLVED FIXED

(Firefox :: Settings UI, defect)

Description

[Mike Kaply [:mkaply]]

If you try to block installs from marketplace.firefox.com on the first run of Firefox, it doesn't work until preferences is opened.

To recreate:

1. Set devtools.chrome.enabled to true.
2. Open the scratchpad.
3. Set the environment to browser.
4. Paste this line:
Services.perms.add(NetUtil.newURI("http://marketplace.firefox.com"), "install", 2);

Now go to preferences, security, exceptions.

Notice that marketplace.firefox.com still says allow.

Now run the command again.

It works.

It also works on subsequent invocations of Firefox.

Comment 1

[Mike Kaply [:mkaply]]

And FYI, this is a real world scenario. Because of this problem, blocking marketplace installs via AutoConfig isn't working on firstrun.

Comment 2

[Mark Hammond [:markh] [:mhammond]]

I can't repro that.  What I did:

* Created a new profile and started nightly with it.
* Hit about:config and set devtools.chrome.enabled = true
* Open a scratchpad, set as browser environment and execute the code you pasted.
* Options->Security->addons exceptions

I see addons.mozilla.org as "Allow" and marketplace.firefox.com as "Block"

Comment 3

[Mike Kaply [:mkaply]]

Looks like it is 33 only. Argh.

Comment 4

[Mike Kaply [:mkaply]]

Broken on 34 (aurora) as well.

Comment 5

[Mike Kaply [:mkaply]]

This was "fixed" here:

https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=5bd6e09f074e&tochange=afc933adf723

Most likely candidate was 

https://bugzilla.mozilla.org/show_bug.cgi?id=1050080

Although it looks like that is going to be backed out. I'm going to go back further and see what actually broke it originally.

Comment 6

[Matthew N. [:MattN]]

(In reply to Mike Kaply (:mkaply) from comment #5)
> https://bugzilla.mozilla.org/show_bug.cgi?id=1050080
> 
> Although it looks like that is going to be backed out. I'm going to go back
> further and see what actually broke it originally.

A partial backout was already done in bug 1073359 to fix non-Firefox applications and no further backout of that bug is planned.

Comment 7

[Mike Kaply [:mkaply]]

Any idea how to work around this bug since we're stuck with it on the ESR?

Comment 8

[Mark Hammond [:markh] [:mhammond]]

I think you are simply seeing the old behaviour WRT default permissions - they are loaded by code as certain modules are loaded.  All the changes in the other bugs you reference were changed in Firefox 35.

In this specific case, the default is loaded via the line in firefox.js:

 pref("xpinstall.whitelist.add.180", "marketplace.firefox.com");

and I can only assume that the code which acts on this pref (XPIProvider.jsm) is lazily loaded as prefs open, and they override the permission you added before this load.  Note that only the very first run of that module will change the permissions, which explains why executing your example code after it's been loaded once sticks.

So in the ESR the solution is to change those prefs, and in the following ESR you will be able to do it in the same way as your example.

Comment 9

[:Gavin Sharp [email: [e-mail]]]

Fixed by bug 506446, then.

Likely wontfix for older ESRs since bug 506446 is not backportable there. We could potentially mitigate this with a more specific fix (e.g. add a notification for when PermissionUtils completes its lazy import of permissions), but since there are alternative ways of doing this, and this behavior has been around for a long time, not sure that's worth it.

Comment 10

[Mike Kaply [:mkaply]]

Agreed. I just put in a workaround.