1991526 - BTP should not initialize before `profile-after-change`

Status: ASSIGNED

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

Description

[Emma Zühlcke [:emz]]

BTP currently initializes lazily. This means when it gets called first it will init the singleton, storage, etc. This can happen before profile init, e.g. in the new profile manager we still seem to end up calling BounceTrackingProtection::RecordUserActivation when a user interacts with it. Initializing this early is not necessary.

We should keep BTP init lazy, but refuse to init when profile-after-change or a similar startup phase indicator has not fired yet.

This was discovered in Bug 1988015.

Comment 1

[Emma Zühlcke [:emz]]

Attachment: Bug 1991526 - Prevent BTP init before profile-after-change. r=#anti-tracking!

Comment 2

[Emma Zühlcke [:emz]]

Attachment: Bug 1991526 - Bypass profile-after-change gate for BTP xpcshell tests. r=#anti-tracking!

Comment 3

[Emma Zühlcke [:emz]]

This change could give us small startup perf gains for scenarios where we e.g. go through the new profile manager. Right now we seem to (attempt to) init on user interaction with the profile manager. After the patch we should only init lazily after the profile has been initialized. It's a bit hard to quantify this potential gain though.