Open Bug 1658825 Opened 4 years ago Updated 4 years ago

Disable profile count collection if we are not going to send it

Categories

(Firefox :: Shell Integration, task)

task

Tracking

()

People

(Reporter: bytesized, Unassigned)

References

Details

Collecting the profile count telemetry (browser.engagement.profile_count) requires disk I/O. It also happens in a user idle callback which can potentially fire (late) in the startup path. Ideally, we should not cause performance degradation in order to collect some data that we don't ultimately use.

At the moment, my understanding is that there isn't an easy way to definitively tell whether telemetry will be sent. For explanation, let me quote the relevant parts of a conversation that took place in this review.

There are a few "telemetry is disabled" thingies. One is the user preference with UI in about:preferences#privacy. Another is the pref itself. A third is "is this a developer build? Pretend it's on, but don't send it". A fourth is "Is this specific probe expired?". A fifth is "What channel is this profile on?". A sixth is "What is the interaction between all these test prefs?". A seventh is "Has the user been given a chance to read the Privacy Notice?".

It looks like either TelemetrySend.sendingEnabled() or TelemetryReportingPolicy.canUpload() would work.

Sadly neither of those is the full story and both are internal implementation details and aren't meant to be APIs for non-Telemetry consumers. No one's needed the full picture before, including Telemetry (each piece only knows its own part).

Severity: -- → S3
You need to log in before you can comment on or make changes to this bug.