Closed Bug 1467059 Opened 6 years ago Closed 19 days ago

add downloads.retry() method

Categories

(WebExtensions :: General, enhancement, P3)

60 Branch
enhancement

Tracking

(Not tracked)

RESOLVED DUPLICATE of bug 1694049

People

(Reporter: johnsheares, Unassigned)

Details

Please add downloads.retry() method to the WebExtension API. This will attempt to continue broken downloads just like when the retry button is used in the download manager.
Can we triage this? Or at least put the bug in the untriaged category?
Flags: needinfo?(cneiman)
Not sure that this one requires a design decision; we can consider this as an enhancement request. :) Geoffrey, do you want to pick this one up?
Severity: normal → enhancement
Flags: needinfo?(cneiman)
Product: Toolkit → WebExtensions
Priority: -- → P3

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

Severity: normal → S3

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()?

Flags: needinfo?(rob)

Hello kernp25,

not sure what you mean by that, so let me confirm:

  1. To my knowledge downloads.download() will start the download, not resuming it.
  2. 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).
  3. 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.
  4. 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?

Flags: needinfo?(geoffreydebelie)

(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.

Flags: needinfo?(geoffreydebelie)

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

Flags: needinfo?(rob)

(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 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

There is a bug 1694049 already filed! If the bug 1694049 gets fixed, then this bug can be closed?

Flags: needinfo?(rob)

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().

Status: UNCONFIRMED → RESOLVED
Closed: 19 days ago
Duplicate of bug: 1694049
Flags: needinfo?(rob)
Resolution: --- → DUPLICATE
You need to log in before you can comment on or make changes to this bug.