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

Status: NEW

(Core :: Graphics, defect)

Description

[Benoit Jacob [:bjacob] (mostly away)]

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?

Comment 1

[Benoit Jacob [:bjacob] (mostly away)]

This was introduced in Bug 625160 - Part 3.

Comment 8

[Benoit Jacob [:bjacob] (mostly away)]

Proposal:
 - 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.

Comment 10

[Mark Callow]

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.

Comment 11

[Benoit Jacob [:bjacob] (mostly away)]

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.

Comment 12

[Rob Janssen]

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.

Comment 13

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

The severity field for this bug is relatively low, S3. However, the bug has 7 duplicates.
:bhood, could you consider increasing the bug severity?

For more information, please visit auto_nag documentation.

Comment 14

[BugBot (nomail) [:suhaib / :marco/ :calixte]]

The last needinfo from me was triggered in error by recent activity on the bug. I'm clearing the needinfo since this is a very old bug and I don't know if it's still relevant.