Closed Bug 1219962 Opened 4 years ago Closed 4 years ago

Addon doesn't seem to be utilizing the blocklist; blocklisted app can still be installed.


(Marketplace Graveyard :: Integration, defect)

Not set


(Not tracked)



(Reporter: nhirata, Unassigned)




(1 file)

Attached file partial locat.txt
1. flash the device
a) For aries install :
b) For flame install :

2. make sure you have settings -> developer -> Debugging via USB = ADB and DevTools
3. make sure Settings->Developer->Use Marketplace Reviewer Certs is checked (you'll also see this in Device Settings as dom.mozApps.use_reviewer_certs)

With WebIDE:
4. In Device Settings, add the string value of dom.mozApps.signed_apps_installable_from to,,
5. add string :  extensions.blocklist.url with value

In browser on device:
5. Go to  ( )
6. Install this app -- it's the dev marketplace package
7. launch the Dev reversion of the Marketplace App.

In Dev Marketplace App:
8. Click on "Add-ons" on the bottom nav
9. Install Unread Icons

Expected: app should be block listed and cannot be installed
Actual: app is installed

Note : Partial logcat ( of when trying to install the addon ) attached.
Testing change : 
step 4.5 : add integer pref : extensions.blocklist.interval value : 30
That's expected - and I commented in the original bug that we need a followup for that but that's defense in depth.

The logic is that for now only the marketplace can ship addons, and it will not ship any that is on the blocklist, right? That would be bad anyway since the device only updates the list once per day.
Yes: once "blocked" in Marketplace, an add-on will no longer be accessible to the public. The blocklist itself is separate but admins that are in charge of blocking are supposed to mark the addon as blocked in Marketplace, then update the blocklist.
Um, well, I tried changing the b2g.js values in the omni.ja and it's still able to install.

So we would have to mark the addon as blocked first before marking the blocklist?  
Shouldn't we just be able to block the addon which then also puts it in the blocklist?
Flags: needinfo?(mpillard)
Krupa ended up blocking the addon on dev, and so now I can't install the addon.

I still don't understand the context of why the blocking of an addon has to happen in two different locations.  I suppose we can close this as either WFM or fixed by blocking and follow up with a different bug of making the block listing off an addon in one location rather than two?
It's in 2 locations because the blocklist is independent of Marketplace (and even of AMO, even through it's handled by AMO at the moment). Later down the road we (or at least I) would like to think about a way to synchronise the 2, but this will do for now.
Flags: needinfo?(mpillard)
You can do that if you want.

Blocklisting needs to encapsulate two actions: the disabling of the addon on the point of acquisition (AMO or Marketplace), and the killing of it out in the wild (Desktop or FxOS). So if it's easier for you to track two things, we can do that.
So im confused here. I wanted to test what happens when a phone receives a request to block an app it already has. So my thought was that I could install the add-on from dev first, THEN enable the dev blocklist (step 5), and see what happens.

But you can't install "Unread icons" because the manifest url returns a 404. Is that intended? The url that isn't working is [1].

If you want to test that flow, then we need to unblock it in Marketplace first, to let you install it. It was blocked because in comment 0 what was tested was the install process.
Blocklisting verified this morning, error was due to an indexing issue.
Closed: 4 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.