1706355 - Download telemetry for added downloads is possibly inflated

Status: VERIFIED FIXED

(Firefox :: Downloads Panel, defect, P2)

Description

[:Gijs (he/him)]

We instrumented the number of downloads in bug 1627676. We did this via the onDownloadAdded handler in DownloadsCommon.jsm.

When I looked at this code this morning for bug 1685737, my impression was that this code runs at every startup, for all items in the downloads history - at least the failed ones that are persisted (cf bug 1685737). This means that the numbers may be artificially inflated.

I actually thought that this applied to all downloads, but I think we might only do this for unsuccessful downloads - I don't see the telemetry on my regular profile (without any unsuccessful downloads) after a restart. Marco, can you help by clarifying when this handler is supposed to get invoked?

I'm worried that this might skew our downloads stats.

Comment 1

[Marco Bonardo [:mak]]

This onDownloadAdded event handler is part of DownloadsDataCtor that is used by various Data objects that basically generate lists of downloads. There are multiple lists of downloads in the product, just that is likely to cause over-counting, and in addition it is also accounting repeated failures as you pointed out.
A Data object is a view over List, and there can be multiple views, thus it's not a good place to track unique downloads.
A better place may be DownloadCombinedList.onDownloadAdded, that should be invoked by private and public Lists when a new public or private download is added. You should still skip downloads that failed to avoid double counting the ones re-added... maybe it would be enough to skip downloads having .stopped? Or you could pass something here to tell "hey we are adding this download from the previous session" https://searchfox.org/mozilla-central/rev/b6f52976b562008c9d9ceeda22907e1eda506c8e/toolkit/components/downloads/DownloadStore.jsm#122

Comment 2

[Micah [:mtigley] (she/her)]

Hi Romain, would you be able to help determine a priority for this?

Comment 3

[Romain Testard [:RT]]

This is not Proton related. I don't think this is particularly urgent though it would be nice to fix it post proton since we'll look into download experience changes soon and measuring the impact of the chance will be good to have.

Comment 4

[Ava Katushka]

Attachment: Bug 1706355 - Move recording new download to telemetry from DownloadsCommon to DownloadsList for more accurate download count

Comment 5

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/ffd2f7c0f1a4
Move recording new download to telemetry from DownloadsCommon to DownloadsList for more accurate download count r=Gijs,mak

Comment 6

[Dorel Luca [:dluca]]

https://hg.mozilla.org/mozilla-central/rev/ffd2f7c0f1a4

Comment 7

[Cristian Baica [:cbaica], Release Desktop QA]

The issue is verified as fixed as part of the sign off work for PI request QA-1075, across all agreed platforms (win 10, ubuntu 20.04 and macOS 10.15). The download entry is no longer duplicated.