add downloads.retry() method
Categories
(WebExtensions :: General, enhancement, P3)
Tracking
(Not tracked)
People
(Reporter: johnsheares, Unassigned)
Details
Comment 1•6 years ago
|
||
Comment 2•6 years ago
|
||
Updated•6 years ago
|
Updated•6 years ago
|
Comment 3•4 years ago
|
||
After the "auto resume downloads" add-on by Maurice Abney (https://addons.mozilla.org/en/firefox/addon/auto-resume-downloads/) doesn't work now for many years, but I'm currently sitting on some downloads which keep failing again and again after a few minutes, I jumped into writing my own add-on.
And I also came across the problem which probably @johnsheares faced: If a download wasn't paused, but interrupted due to an error, Firefox (in my case v87.0) doesn't allow resuming it by using downloads.resume().
Such a DownloadItem has the following values:
canResume: false
error: 'NETWORK_FAILED'
exists: false
paused: false
state: 'interrupted'
If I still pass the ID of the download to the resume() method, I get an error in the catch() method of the returned promise object that the download can't be resumed.
The fun thing is: If I press the resume button in the built-in download manager of Firefox, the download resumes without any problem. So there is at least no technical reason it shouldn't work.
Not sure if that has any influence on this, but the download is initially triggered by another add-on. But I don't see any functionality in the API with which an add-on can change the behaviour of downloads (like intercepting the resume request of the user and perform additional steps).
Not sure if that is intentional, a misunderstanding on my side or simply a bug. Would be nice if someone could shed some light on this matter (or fix the bug, if it is a bug).
A little side node: When I analysed the problem I came across some add-ons for Chrome and had a look at their source code. Seems they do more or less what I'm trying to do. And many users complain that those add-ons don't work since some time in the 2nd half of 2018.
I'm actually in the exact same scenario as Gerrit, I encountered a website with downloads that always interrupt with network failed, and tried to make my own extension to resume them after finding "auto resume downloads" no longer works, but found the resume function was unable to resume, despite it working within Firefox.
I tested the same website on Google Chrome with chrome.downloads, and it resumes perfectly fine as expected.
Firefox v96.0.3
Updated•2 years ago
|
Does this makes sense? Can this not be done already with downloads.download()
?
When pressing the retry button in the built-in download manager of Firefox, does the download always start again from zero?
Or does the retry button work like downloads.resume()
? It continues the download where it was interrupted?
Would there be a difference between downloads.download()
and downloads.retry()
?
Comment 7•1 month ago
|
||
Hello kernp25,
not sure what you mean by that, so let me confirm:
- To my knowledge
downloads.download()
will start the download, not resuming it. - When pressing retry in the UI, Mozilla will try to to resume the download, not restart it from zero. That being said, it of course only works if the server supports it (
Content-Range
header). - So the retry button works like I would expect
downloads.resume()
to work. Maybe except that it may through an exception when resume is not possible due to the server instead of simply starting from scratch. But I'm not sure what the Web API's definition here is. - So, yes, there is a fundamental difference between the two methods / functions.
By the way, Mozilla's own description of downloads.resume()
states how it should work - except it doesn't in Firefox. It also states that is working since Firefox v48. Very interesting. Means this information is a) false or b) it worked at some point (at least in v48) like intended and then was broken. That would also explain why add-ons like "auto resume downloads" exist using this functionality. If it would have never worked, those authors would never have published their add-ons, wouldn't they?
See also: chrome.downloads | API | Chrome for Developers - resume()
Geoffrey, do you want to pick this one up?
Are you going to work on this?
Comment 9•1 month ago
|
||
(In reply to kernp25 from comment #8)
Geoffrey, do you want to pick this one up?
Are you going to work on this?
I have no experience working in the Firefox codebase. I only develop add-ons.
Comment 10•29 days ago
|
||
This bug asks for downloads.retry
, but the requested functionality (continue partial downloads) is already supposedly offered by downloads.resume()
.
There are some comments above that report that resume()
does not work, including comment 3. If that is the case, please file a new bug report with a specific test case.
In comment 3, the DownloadItem has an error (NETWORK_FAILED), which could explain why resume()
refuses to continue - internally resume()
only continues if canResume
is true, which is false when there is an error: https://searchfox.org/mozilla-central/rev/b655023a1978bcad8cc2fb038b89a058b45e91a7/toolkit/components/extensions/parent/ext-downloads.js#236-241
Comment 11•26 days ago
|
||
(In reply to Rob Wu [:robwu] from comment #10)
This bug asks for
downloads.retry
, but the requested functionality (continue partial downloads) is already supposedly offered bydownloads.resume()
.There are some comments above that report that
resume()
does not work, including comment 3. If that is the case, please file a new bug report with a specific test case.In comment 3, the DownloadItem has an error (NETWORK_FAILED), which could explain why
resume()
refuses to continue - internallyresume()
only continues ifcanResume
is true, which is false when there is an error: https://searchfox.org/mozilla-central/rev/b655023a1978bcad8cc2fb038b89a058b45e91a7/toolkit/components/extensions/parent/ext-downloads.js#236-241
There is a bug 1694049 already filed! If the bug 1694049 gets fixed, then this bug can be closed?
Comment 12•19 days ago
|
||
Yes. I'll close as a duplicate of bug 1694049 : When the bug with canResume
and downloads.resume()
is fixed, then it would behave as requested here. There is no point in adding another downloads.retry()
method.
If an extension wants to retry a download (completely start over again), they can use downloads.download()
.
Description
•