Make blocklist APIs asynchronous

RESOLVED FIXED

Status

()

enhancement
RESOLVED FIXED
a year ago
a month ago

People

(Reporter: Gijs, Assigned: Gijs)

Tracking

Trunk
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(firefox61 affected)

Details

(Whiteboard: [fxperf:p1])

Assignee

Description

a year ago
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.
Assignee

Comment 2

a year ago
(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. :-)
Assignee

Updated

a year ago
Depends on: 1451487
Assignee

Updated

a year ago
Depends on: 1451743
Assignee

Updated

a year ago
Depends on: 1452618
Assignee

Updated

a year ago
Depends on: 1454456
Assignee

Updated

a year ago
Depends on: 1456171
Depends on: 1456291
Assignee

Updated

a year ago
Depends on: 1456515
Depends on: 1456677
Assignee

Comment 3

a year ago
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? :-)
Flags: needinfo?(mathieu)
Assignee

Comment 5

a year ago
I believe all the publicly-exposed methods are now async.
Status: ASSIGNED → RESOLVED
Last Resolved: a year ago
Resolution: --- → FIXED
Assignee

Comment 7

a year ago
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.
Flags: needinfo?(mathieu)
Component: Blocklist Policy Requests → Blocklist Implementation
You need to log in before you can comment on or make changes to this bug.