Open Bug 653102 Opened 9 years ago Updated 4 years ago

Do Not Cache the blacklisting decisions; instead cache the downloaded blacklist entries and reevaluate everytime


(Core :: Graphics, defect)

Not set




(Reporter: bjacob, Unassigned)


(Blocks 2 open bugs)


GfxInfo is currently caching as prefs the blacklisting decisions: these are the gfx.blacklist.* prefs.

This is only getting re-evaluated once a day.

In principle that only applied to the downloaded blacklist but in practice that applies also to the compiled-in blacklist.

Proposed changes:
 * do not cache blacklisting decisions
 * cache the downloaded blacklist itself to avoid having to re-download it everytime. Though, I would naively assume that such AMO blocklist caching is already being performed without us having to do anything about it?
This was introduced in Bug 625160 - Part 3.
Blocks: 625160
Duplicate of this bug: 660730
Blocks: 668008
Duplicate of this bug: 680769
Duplicate of this bug: 693126
Duplicate of this bug: 716264
Duplicate of this bug: 653799
Duplicate of this bug: 734297
Blocks: 711656
Blocks: 737176
 - evaluate all the blocklist early at startup, in a separarate thread, so we hopefully don't delay firefox startup significantly. The result of that operations is a pre-computed blocklisting decision for each gfx feature. So you could call that a cache, except that it's not persistent, it's not stored in prefs.
 - Drop gfx.blacklist.* prefs altogether.
 - at startup, do also precompute a hash value aggregating any data point that may invalidate the precomputed blocklisting decisions. This would include e.g. device ID, driver version, etc.
 - when initializing a gfx feature, recompute the invalidation hash. If it agrees with the precomputed one, use the precomputed blocklisting decisions. If it doesn't agree, re-evaluate the blocklist for all gfx features and update the saved invalidation hash.
Duplicate of this bug: 756370
Probably what triggered the issue in my case (bug #756370) is that I had been running FF in Windows 7 from bootcamp via a VM. I then rebooted bootcamp's Win7 directly on the hardware. Probably the blacklisting was valid when running under the VM and the cache carried it forward over the reboot.
I see. Your case would be appropriately handled if we had a proper invalidation mechanism for this cache, which we don't at the moment.
Additionally, evaluations of the hardware (capabilities or problems) should NEVER be stored in the user profile.
In a company network, the user profile is usually roaming.  I.e. it is retrieved from a network server when the user logs in, gets modified during the user session, and is then stored again on the server when the user logs out.
However, those user login sessions can be (and will be) on different computers, where different evaluations of the hardware can be made.
It makes no sense to have those evaluations roam from one computer to the next in the user profile.
You need to log in before you can comment on or make changes to this bug.