1308948 - cannot retry failed download

Status: RESOLVED WORKSFORME

(Toolkit :: Downloads API, defect)

Description

[Carlin Scott]

User Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:47.0) Gecko/20100101 Firefox/47.0
Build ID: 20160623154057

Steps to reproduce:

tried to download a 18Mb file on a unreliable wifi connection.


Actual results:

the download failed 12Mb in, I clicked retry dozens of times without it resuming successfully.

I found this workaround that worked perfectly: http://www.techsive.com/2014/09/how-to-resume-failed-downloads-in.html


Expected results:

the download should have resumed and eventually completed.

Comment 1

[Loic]

Do you know if the server is able to resume downloads?

Comment 2

[:Paolo Amadini]

Can you provide step-by-step instructions for a test case where you cannot normally resume the download by clicking the "retry" button, but you can resume it successfully if you use the workaround described in the article?

Comment 3

[Carlin Scott]

Steps to reproduce:
1. Start downloading https://github.com/boot2docker/boot2docker/releases/download/v1.12.2/boot2docker.iso
2. Wait until you have downloaded some of the file (~12mb)
3. Disconnect from the internet and let the download fail
3. Reconnect to the internet
4. Attempt to resume the download
5. Follow workaround directions found here: http://www.techsive.com/2014/09/how-to-resume-failed-downloads-in.html

Comment 4

[:Paolo Amadini]

Thanks! I tried in a Windows 7 virtual machine and I cannot reproduce this bug.

In the first part of step 3, I'm disconnecting the host only, so the operating system does not notice the network change and the download fails (otherwise the download would be paused automatically).

After step 4, the download resumes from where it left, using the data already on disk.

This is both with Firefox 49.0.1 and with Nightly.

Comment 5

[Loic]

Same here, I can't reproducie it on Win 7. When my wifi is turned off, the download gets paused (yellow progress bar). When I reconnect the wifi, the download resumes.

Comment 6

[Carlin Scott]

@loic that's interesting; My progress bar stays green and then just goes away. I did exactly what you did too. I don't have my wifi set to reconnect automatically though so maybe that is somehow related?

Can I collect some logs to help wit this?

Comment 7

[:Paolo Amadini]

You can tick "Enable remote debugging" from the Developer Tools advanced options, then under "Developer" in the main menu you can open the "Browser Toolbox" and use the "Network" tab to see what happens on the network during your step 4.

Differently from Loic, you're seeing a case where Firefox does not detect the network disconnection, but this is indifferent because for us the download resumes correctly in both cases.

Comment 8

[Carlin Scott]

So the network debugger, nor the browser console show anything when I try to resume the download. I collected Wireshark logs and it looks fine but the download is encrypted so all I can see is that it finished the handshake and received a couple data packets before abruptly stopping.

Using Fiddler I managed to find some interesting behavior. The first time the download failed to resume, it was challenged by a 403 but immediately made a successful connection and got the proper response from the server. All subsequent resumes immediately stop after connecting to the server.

I also had trouble reproducing this on a better wifi connection but was able to by repeatedly cycling through steps 2-4.

Comment 9

[:Paolo Amadini]

Thanks for doing the debugging! It seems that there is little we can do on our side, unfortunately, as the reason for the failure is that the server intermittently fails to resume. When this happens, by network protocol design, the server simply re-sends all the data from the beginning, and we have to overwrite the local data with the new data sent by the server.

The solution in the article would have the same problem, and would work intermittently too. Nowadays, it's just a way for you to preserve some of the data and manually try again if needed. At the time, we didn't try to resume failed downloads at all, so that's why the article was originally written.

Comment 10

[Carlin Scott]

I disagree with the assessment of this issue and the resolution chosen. This issue is reproducible for anyone by following my instructions and the workaround works 100% of the time but is really annoying if it has to be done multiple times for the same file.

Firefox does not "have to overwrite the local data with the new data sent by the server." It can do exactly what the workaround does, which is create a new download session and then use the already downloaded data to resume where it left off. DownloadThemAll works around this issue but I have it disabled most of the time because it adds extra context menu options. 

If someone wants to address this issue with an update to the FF code, they should be allowed to do that.

PS. I have reproduced this on multiple websites and the workaround always works.