763812 - blocklist.xml shouldn't be stored per-profile/per-application

Status: RESOLVED INACTIVE

(Toolkit :: Add-ons Manager, defect)

Description

[Blair McBride [:Unfocused] (UNAVAILABLE)]

Currently the blocklist data is stored in the current profile. Which means that every profile (including every app using WebAppRT) re-fetches the same data, and stores is separately.

If the data is stored in one location (ie, not per profile), then:
* Less data re-fetched
* Less disk space used
* Blocklist data will be (on average) more recent

Not sure how that will fit in with measuring blocklist pings.

Comment 1

[Dave Townsend [:mossop]]

(In reply to Blair McBride (:Unfocused) from comment #0)
> Currently the blocklist data is stored in the current profile. Which means
> that every profile (including every app using WebAppRT) re-fetches the same
> data, and stores is separately.
> 
> If the data is stored in one location (ie, not per profile), then:
> * Less data re-fetched

This is only true if we implemented some scheme to only download when there was new data. Right now we just download the entire file regardless every day. We were talking last week about how we may need to get smart as the blocklist grows to improve this anyway though.

> * Less disk space used
> * Blocklist data will be (on average) more recent
> 
> Not sure how that will fit in with measuring blocklist pings.

So long as they only measure the pings from "Firefox" itself it shouldn't affect it I think, but always best to give the metrics guys a heads up.

The only issue that springs to mind is that right now edits made to blocklist.xml from outside of Firefox don't get detected by Firefox. We'd have to start tracking last modified time of the file or something to know to re-load the file and apply any changes to add-ons.

Comment 2

[Blair McBride [:Unfocused] (UNAVAILABLE)]

(In reply to Dave Townsend (:Mossop) from comment #1)
> The only issue that springs to mind is that right now edits made to
> blocklist.xml from outside of Firefox don't get detected by Firefox. We'd
> have to start tracking last modified time of the file or something to know
> to re-load the file and apply any changes to add-ons.

I had wondered about keeping a serial number associated with blocklist.xml (it can be in the XML that AMO sends), and sending that in the HTTP request. If the blocklist hasn't changed since, AMO can respond with a 304 or 418 or something. But... that doesn't really address manual edits.

Comment 3

[Dave Townsend [:mossop]]

(In reply to Blair McBride (:Unfocused) from comment #2)
> (In reply to Dave Townsend (:Mossop) from comment #1)
> > The only issue that springs to mind is that right now edits made to
> > blocklist.xml from outside of Firefox don't get detected by Firefox. We'd
> > have to start tracking last modified time of the file or something to know
> > to re-load the file and apply any changes to add-ons.
> 
> I had wondered about keeping a serial number associated with blocklist.xml
> (it can be in the XML that AMO sends), and sending that in the HTTP request.
> If the blocklist hasn't changed since, AMO can respond with a 304 or 418 or
> something. But... that doesn't really address manual edits.

We added the lastupdate attribute to the XML some time ago (I was thinking of using it to select between the profile and app blocklist file but never got around to that bit). We could conceivably send that in an If-Modified-Since header and have AMO return a 304 if there is nothing newer.

Comment 4

[BMO Automation]

Per policy at https://wiki.mozilla.org/Bug_Triage/Projects/Bug_Handling/Bug_Husbandry#Inactive_Bugs. If this bug is not an enhancement request or a bug not present in a supported release of Firefox, then it may be reopened.