1630939 - URLDecorationAnnotationsService started very early during startup (profile-after-change)

Status: NEW

(Core :: Privacy: Anti-Tracking, defect, P3)

Description

[:Gijs (he/him)]

Splitting this discussion out of bug 1626935.

It seems the url decoration annotation service gets created relatively early during startup (profile-after-change for the decoration service courtesy of https://searchfox.org/mozilla-central/rev/567b68b8ff4b6d607ba34a6f1926873d21a7b4d7/toolkit/components/antitracking/antitracking.manifest#1).

This is work that does not seem to be required on startup. There was some concern in bug 1626935 about syncing things - but I'm pretty sure remote settings won't do a sync in the middle of startup no matter how early we call the RemoteSettings constructor - it runs off the remote settings sync timer, which is an update timer, and those shouldn't be running in the middle of startup. In terms of the sync behaviour, AFAICT it does not care whether that particular client has been instantiated during that run - it'll update anything it's ever heard of, and create clients as necessary ( https://searchfox.org/mozilla-central/rev/567b68b8ff4b6d607ba34a6f1926873d21a7b4d7/services/settings/remote-settings.js#300-306 ).

If the pageload of fb.com from session restore should block on getting the contents of this DB from disk into memory, then that should probably be implemented more explicitly (ie the channel should not finish with AsyncOpen until we have the data) - right now I don't think there's any guarantee that it will be complete by the time we start making network requests.

Comment 1

[Andrew Creskey [:acreskey]]

The classifier delays we're seeing in the current (Fenix) startup scenario are primarily captured in bug 1956920, bug 1956923, bug 1984478, and bug 1933562 so we're demoting the perf-impact on this one to low for now.