In bug 1257565 we'd like to switch to another data format for storing blocklist information. To do this, ultimately we need to make the APIs that get information from the blocklist service asynchronous, so that we can fetch the data for the blocklist asynchronously. This bug tracks that work. bug 1371888 made this slightly easier by changing the plugin code to cache blocklist state per plugin, and assuming 'not blocked' state for new sideloaded plugins when they are encountered. It then synchronously fetches state when the blocklist does load. As part of this bug I intend to update the plugin code to use asynchronous APIs to fetch that data. I also intend to do a similar thing to the add-ons code (store blocklist state inasmuch as we don't already, update asynchronously (ie "sometime later") for new items). All of this to eventually move to a storage surface that only provides async access, like (say) sqlite, or a JSON->memory thing that we'd like to load OMT, etc.

(In reply to :Gijs from comment #0) > As part of this bug I intend to update the plugin code to use asynchronous > APIs to fetch that data. I also intend to do a similar thing to the add-ons > code (store blocklist state inasmuch as we don't already, update > asynchronously (ie "sometime later") for new items). There doesn't need to be a "sometime later". Add-on installs are already async, and already only check the blocklist status at add-on install and blocklist update time. They can just do an async blocklist query whenever they need to update that information. The one caveat is that side-loaded extensions detected at startup are a weird sort of hybrid. They're synchronously "installed", and then enabled after users opt in. We should really rework that process, but we can also just block the side-load install prompts on the blocklist state check.

(In reply to Kris Maglione [:kmag] (long backlog; ping on IRC if you're blocked) from comment #1) > The one caveat is that side-loaded extensions detected at startup are a > weird sort of hybrid. They're synchronously "installed", and then enabled > after users opt in. We should really rework that process, but we can also > just block the side-load install prompts on the blocklist state check. Right, when I looked at callers I noticed a fully synchronous codepath into the blocklist from a function literally called "syncLoadDB". If that's fine with being updated later (ie not really being fully sync anymore), good - it just wasn't super obvious to me. :-)

Mathieu, I'm about to land bug 1456515. Do you think it's possible for you to take on bug 1257565 for 62 when that's fixed? :-)

\o/

I believe all the publicly-exposed methods are now async.

\o/

Mathieu and I talked out-of-band. I'll be pursuing bug 1257565 and he's making some changes to kinto to help ease that process.