URLDecorationAnnotationsService started very early during startup (profile-after-change)
Categories
(Core :: Privacy: Anti-Tracking, defect, P3)
Tracking
()
People
(Reporter: Gijs, Unassigned)
References
(Blocks 1 open bug)
Details
(Keywords: perf:startup)
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.
Updated•3 years ago
|
Updated•3 years ago
|
Updated•3 years ago
|
Reporter | ||
Updated•1 year ago
|
Reporter | ||
Updated•1 year ago
|
Description
•