852484 - Get rid of blocklisted state caching on the plugin tags

Status: RESOLVED WONTFIX

(Core Graveyard :: Plug-ins, defect, P3)

Description

[Georg Fritzsche [:gfritzsche]]

In bug 830267 we're getting rid of the plugin flags, which include the blocklisted flag.
For now we are using the prefs to store this, but we'd like to get rid of it.

From a earlier discussion with Mossop i recall that the blocklisted state caching per plugin was required at some point to avoid hitting the blocklist service and the associated file IO during startup.

Do we have a specific use-case that needs this? If yes, couldn't the blocklist service do the caching itself?

Comment 1

[Dave Townsend [:mossop]]

(In reply to Georg Fritzsche [:gfritzsche] [at Performance work-week] from comment #0)
> In bug 830267 we're getting rid of the plugin flags, which include the
> blocklisted flag.
> For now we are using the prefs to store this, but we'd like to get rid of it.
> 
> From a earlier discussion with Mossop i recall that the blocklisted state
> caching per plugin was required at some point to avoid hitting the blocklist
> service and the associated file IO during startup.

It used to be the case that the plugins were enumerated early in startup (I think because the default start page checked for outdated flash) and we wanted to avoid loading the blocklist xml and slowing that down. pluginreg.dat had to be loaded for the plugins anyway so it was cheap to stick it there. I don't know if that still happens at startup, though it seems likely it does for some people.

> Do we have a specific use-case that needs this? If yes, couldn't the
> blocklist service do the caching itself?

Possibly, though we'd have to cache all the regex rules we use in prefs which is not great. An alternative is investigating storing the blocklist.xml in a nicer format that is faster for us to parse. When we parse the XML we generate what I think is just pure JS, maybe just persisting that as JSON would make for faster loading times as the only parsing necessary is a JSON decode.

Comment 2

[Blair McBride [:Unfocused] (UNAVAILABLE)]

Aaaand another reason we need bug 782261.

Is there any real reason to avoid using a pref in the meantime? We don't really have the problem of 3rd parties tempering with plugin settings like we do with add-ons, as there isn't the incentive for them to do so. And anything really malicious that would try to do that would already have system privileges anyway.

Comment 3

[Georg Fritzsche [:gfritzsche]]

(In reply to Blair McBride [:Unfocused] (Back from the dead. Mostly.) from comment #2)
> Is there any real reason to avoid using a pref in the meantime?

No, the planned rewrite should cover it.

Comment 4

[BMO Automation]

Resolving as wont fix, plugin support deprecated in Firefox 85.