Download telemetry for added downloads is possibly inflated
Categories
(Firefox :: Downloads Panel, defect, P2)
Tracking
()
Tracking | Status | |
---|---|---|
firefox90 | --- | verified |
People
(Reporter: Gijs, Assigned: ava8katushka)
References
Details
Attachments
(1 file)
(deleted),
text/x-phabricator-request
|
Details |
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•4 years ago
|
||
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•4 years ago
|
||
Hi Romain, would you be able to help determine a priority for this?
Comment 3•4 years ago
|
||
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.
Reporter | ||
Updated•3 years ago
|
Assignee | ||
Comment 4•3 years ago
|
||
Updated•3 years ago
|
Updated•3 years ago
|
Updated•3 years ago
|
Updated•3 years ago
|
Comment 6•3 years ago
|
||
bugherder |
Comment 7•3 years ago
|
||
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.
Description
•