[Affected versions]:

• Firefox 65.0
• Firefox 66.0b5
• Nightly 67.0a1

[Affected Platforms]:

• Windows 10 x64
• macOS 10.12
• Ubuntu 18.04 x64

[Steps to reproduce]:

• Go to https://www.thinkbroadband.com/download
• Download a file.
• Open the download dropdown and paused the download.
• Resume the download.

[Expected results]:

• The download continues from where it was paused.

[Actual results]:

• The download starts from the beginning.

[Regression range]:

• I am not sure that this is a regression. I can reproduce the issue on Nightly from 2014-01-02 and before that the pause button is not working, so I can't find the regression.

Oana, Marco, Felipe and me all tried to reproduce. Marco and I (both based in Europe) had no problems resuming (ie things worked correctly); Felipe (from Latin America) couldn't even get the download to start. It's quite likely it matters quite a bit what network you're on etc. Are you using a proxy? Can you try from a different network? And which specific downloads are you trying (and which ports) ?

I did a bit of investigation on this part. These are the results:

• I download usually the 100Mb (from the link in the comment 0) so I have enough time to pause the progress.
• I am not using a proxy.
• while using VPN (China, Switzerland, UK, France, even from Brazil, Chile and Argentina) the issue didn't reproduce.
• while using a different network the bug did not reproduce (I made a hotspot on one of our laptops).

I don't know how I can find the port. Can you please give me some steps?

On the downloads page there are various links for IPV4 and IPV6 on different ports (80, 81, ...), I think Gijs was just asking which of those links you reproduced with.

(In reply to Marco Bonardo [::mak] from comment #3)

On the downloads page there are various links for IPV4 and IPV6 on different ports (80, 81, ...), I think Gijs was just asking which of those links you reproduced with.

Yep, that's right.

(In reply to Oana Botisan, Desktop Release QA from comment #2)

I did a bit of investigation on this part. These are the results:

• I download usually the 100Mb (from the link in the comment 0) so I have enough time to pause the progress.
• I am not using a proxy.

You're sure that if Firefox is using the system network settings or auto-detect network settings, there's no proxy? Or you tested with forcing the "no proxy" option in network settings, restarting Firefox (to be sure) and then the download works but pause/resume fails?

Do you know what kind of firewall/antivirus the network has, and/or can you bring someone on the bug who knows?

Really interesting that this is so network dependent. It looks like the download links are plain http (ie not TLS/SSL-secured using https:) and so I suspect something is messing with the network requests. The question is what, and if Firefox could do something about it.

Does pause/resume work for downloads on this page in any other browsers when you're on the network where it doesn't work in Firefox?

I reinvestigated everything.

• I used the IPv4 Port: 80, 81 and 8080 and the bug is reproducing.
• when I try to download from IPv6 Port, the "Hmm. We're having trouble finding that site." page is loaded.
• I set the "Connection Settings" from the browser to "No proxy", "Auto-detect proxy settings for this network" and "Use system proxy settings" (restarted Firefox between sessions) and the bug is still reproducing.
• I am using Kaspersky Endpoint Security for Windows v.11.0.0.6499, but on macOS and Ubuntu we don't have any antivirus only the company's firewall (SonicWall).
• On Chrome the issue is not reproducing.

(In reply to Oana Botisan, Desktop Release QA from comment #5)

I reinvestigated everything.

• I used the IPv4 Port: 80, 81 and 8080 and the bug is reproducing.
• when I try to download from IPv6 Port, the "Hmm. We're having trouble finding that site." page is loaded.
• I set the "Connection Settings" from the browser to "No proxy", "Auto-detect proxy settings for this network" and "Use system proxy settings" (restarted Firefox between sessions) and the bug is still reproducing.
• I am using Kaspersky Endpoint Security for Windows v.11.0.0.6499, but on macOS and Ubuntu we don't have any antivirus only the company's firewall (SonicWall).
• On Chrome the issue is not reproducing.

Thanks. Most mysterious. Can you get wireshark traces for these downloads + their resumes, for the ipv4 port 80 case, one from Firefox and one from Chrome, on either mac or linux?

I installed wireshark on macOS 10.13 and I downloaded a file from IPv4 Port 80 on both Chrome and latest Nightly and then I tried to filter the results in wireshark so that only the "ipv4" to be displayed... but nothing was displayed. Only ipv6 processes are displayed, which is strange, because I can't seem to download the files from IPv6.
Or maybe I am doing something wrong can you please give me a screen cast?
Thank you.

It should be possible to filter the http packets based on the target host by determining where the download comes from, does that not work?

See the packet captures, one for Firefox 66.0b7 and one for Chrome. For each of these captures I went to https://www.thinkbroadband.com/download and started downloading the 200 MB file over IPv4, paused the download, then resumed. The server's IP address was 80.249.99.148.

(In reply to Oana Botisan, Desktop Release QA from comment #9)

See the packet captures, one for Firefox 66.0b7 and one for Chrome. For each of these captures I went to https://www.thinkbroadband.com/download and started downloading the 200 MB file over IPv4, paused the download, then resumed. The server's IP address was 80.249.99.148.

I don't see any resumption at the http level in the chrome capture. At what point in the capture did the pause/resume happen? And, if you wait a full 5-10 minutes after pausing / before resuming, do you get the same result in Chrome?

Marco, can you doublecheck what I'm seeing (comment #10) in the capture files (comment #9 ) ? Thanks.

yeah, in our log I see 2 requests for the 200MB.zip file, the second request doesn't seem to consider the channel as resumable.
In Chrome's log I see just a single request, maybe they stop requests after a while and that time didn't elapse yet.

(In reply to :Gijs (he/him) from comment #10)

I don't see any resumption at the http level in the chrome capture. At what point in the capture did the pause/resume happen? And, if you wait a full 5-10 minutes after pausing / before resuming, do you get the same result in Chrome?

I paused a few seconds after I started the download. And it doesn't matter how much time you let the download on pause on Chrome it resumes from where the progress was when I paused it.

So I'm assuming there's a difference in how we pause downloads and how Chrome does so. I'm a little confused because the implementation for pause() at https://searchfox.org/mozilla-central/rev/dc0adc07db3df9431a0876156f50c65d580010cb/browser/components/downloads/DownloadsViewUI.jsm#693 seems to just be identical to canceling the download. Paolo, can you clarify?

If we're closing the http channel and having to resend things when resuming, I wonder if instead we could just stop sending TCP requests for more data, and resume doing so when the download resumes, or something like that, but in order to ask the right questions from the relevant networking people it'd seem helpful to understand how our current implementation actually works...

Whether a download looks paused, canceled, or failed in the front-end, the network request is always stopped. This happens also when downloads are paused automatically at the end of a browsing session or when going offline.

We distinguish between a canceled and a paused download based on whether the download has partial data that we're storing locally in a ".part" file. When resuming, we try to use a range requests to avoid downloading the same data again. If the server does not support range requests, we disable the pause command in the front-end. If the server said it supported range requests, but it fails to resume, we delete the partial data and start downloading again from the beginning.

Canceling is similar to pausing, but also makes sure that any partial data we have is deleted.

We can suspend requests at the network level, this is done for example when the BackgroundFileSaver memory buffer is full because we couldn't write the data to disk fast enough. However, servers may fail to resume if the request is suspended for a long time. I don't know whether this is what Chrome does when a download is paused.