Open
Bug 1256243
Opened 10 years ago
Updated 1 year ago
extra chrome.downloads.onChanged events generated during cancel
Categories
(WebExtensions :: Request Handling, defect, P5)
WebExtensions
Request Handling
Tracking
(Not tracked)
NEW
People
(Reporter: aswan, Unassigned)
References
(Blocks 1 open bug)
Details
(Whiteboard: [downloads]triaged)
When a download is canceled, it goes through a state that looks very much like a paused download (ie, the transfer has been canceled but we haven't yet removed the partial data ffrom disk).
As a result, we generate multiple onChanged events, one in which paused and canResume go from false to true, then a second in which those fields go back from true to false and error goes to USER_CANCELED.
Note that there are multiple ways a download can be canceled, and we'll want to make sure we catch all of them, including Download.finalize() [1] as well as via the UI [2]
[1] https://dxr.mozilla.org/mozilla-central/rev/f0c0480732d36153e8839c7f17394d45f679f87d/toolkit/components/jsdownloads/src/DownloadCore.jsm#1003
[2] https://dxr.mozilla.org/mozilla-central/rev/f0c0480732d36153e8839c7f17394d45f679f87d/browser/components/downloads/DownloadsViewUI.jsm#290
(see also discussion in bug 1245602)
Updated•10 years ago
|
Whiteboard: [downloads] → [downloads]triaged
Updated•9 years ago
|
Component: WebExtensions: Untriaged → WebExtensions: Request Handling
Priority: -- → P5
Updated•8 years ago
|
Depends on: webextensions-code-debt
Updated•8 years ago
|
Product: Toolkit → WebExtensions
Updated•8 years ago
|
Blocks: webextensions-code-debt
No longer depends on: webextensions-code-debt
Updated•3 years ago
|
Severity: normal → S3
You need to log in
before you can comment on or make changes to this bug.
Description
•