Closed Bug 798005 Opened 9 years ago Closed 4 years ago

Add resume support to the stub installer instead of downloading from the beginning.


(Firefox :: Installer, defect, P1)

11 Branch
Windows 7



Firefox 58
Tracking Status
firefox58 --- verified


(Reporter: jsmith, Assigned: mhowell)



(Whiteboard: [stubv3-])


(1 file)


1. Launch the stub installer with an internet connection
2. Start the download phase by selecting install
3. When the progress bar starts filing, cut the internet connection
4. Wait a few minutes
5. Add the internet connection back


The progress bar I would think would return back to where I was left off before the internet connection was done. So if I was 30% done, I should start again from 30% and continue.


The progress bar starts from 0% again. From the user's perspective, it sends the message that I'm redoing the download of all the resources again. Is this true? Or is the perception of progress not right here?
If the connection isn't restored before the request timeout it starts from the beginning. This is planned as a ver 2 of the stub installer.
Summary: On partial completion of the download phase of the stub installer, if I cut the internet connection some long period of time, then bring back the internet connection, the download phase appears to resume from the beginning from the user's perspective → Add resume support to the stub installer instead of downloading from the beginning.
Duplicate of this bug: 798845
Whiteboard: [stub-]
Duplicate of this bug: 836232
Whiteboard: [stub-] → [stubv2-]
Whiteboard: [stubv2-] → [stubv3-]
Assignee: nobody → mhowell
Priority: -- → P2
Gonna try to get this in for 58.
Priority: P2 → P1
Adam, there's no big rush on this review. I'd like to get this in during the 58 cycle, but if it gets pushed back even past that it's totally fine.

I've manually tested this by using Fiddler to interrupt the download in progress, and observed there that it does pick up from where it left off. Also the installation following that interrupted download succeeds.
Comment on attachment 8915693 [details]
Bug 798005 - Resume interrupted downloads in the stub installer, instead of starting over.
Attachment #8915693 - Flags: review?(agashlin) → review+
Pushed by
Resume interrupted downloads in the stub installer, instead of starting over. r=agashlin
Closed: 4 years ago
Resolution: --- → FIXED
Target Milestone: --- → Firefox 58
Flags: qe-verify+
Just to clarify for the sake of verification in Comment 6:

When internet connection is interrupted before the installation process: It will start over or prompt an error message saying there was an error and to start over.

When internet connection is interrupted after installation begins: It will continue to install Firefox whether or not connection is working.

Is this analysis correct?
Flags: needinfo?(mhowell)
You've described the expected behavior prior to this patch. With this patch, the connection being interrupted before the installation process starts should no longer result in starting over; the download should instead continue from where it left off once the connection is restored. The error message should still appear eventually, though, if the connection stays broken for a while (technically this happens after 10 retries, but it will no longer be clear to the user when a retry has happened). And the behavior after installation begins should be unchanged.
Flags: needinfo?(mhowell)
As of today's Nightly, I'm seeing the behavior in Comment 12 when dealing with the Stub Installer. Are you seeing this issue?
Flags: needinfo?(mhowell)
No, it's resuming correctly for me. I wonder if this is related to whatever triggered bug 1416295, which looks like something that's intervening in the network at SV in Romania and disabling resuming any downloads. Do you think you could send me a Wireshark capture of a download attempt? That would show if anything like that is going on.
Flags: needinfo?(mhowell)
I managed to reproduce this bug on Windows 10 x64 using beta 58.0b1 stub installer. I blocked the internet connection using NetLimiter 4  while the progress bar started to fill. After the internet was reconnected the process bar started from 0%. 
I tested it using beta 58.0b5 stub installer and I got the same behaviour.
I can reproduce using NetLimiter as well. It seems to have a more interesting way of killing the connection than what you get using other tools or by just yanking the network cable; I can't tell exactly what it's doing because nothing shows up in Wireshark that looks like the end of a connection. I think I can still work around it though; I'll file a followup bug.
Blocks: 1421354
I tried to reproduce this bug using two methods and I got different results using stub installer for beta 55.0b4 and beta 58.0b13

1. I pulled the internet cable out of the computer:
    - the progress bar resumes from the exact point where it was when the connection was interrupted.

2. I disabled the connection from Control Panel\All Control Panel Items\Network and Sharing Center\Ethernet Status
    - the progress bar started from 0% using both of the stub installers. 

And if I use NetLimiter, this problem is still reproducing.
Please file a follow-up bug for that second case; I doubt its a very high-value case to fix, but it may be easy enough that it gets done anyway.

I couldn't reproduce with NetLimiter anymore after bug 1421354 was fixed, and I could before that, so I had thought that case was fixed. Not sure what's still happening with that, but again it's an edge case; I'm more interested in the "pull the Internet cable out" test, because I think that one's more realistic.

I managed to reproduce this bug on an older version of beta (55.0b4) by using the tools Fiddle 4 and Net Balancer. I retested everything using beta 58.0b15 and the bug is not reproducing anymore.

I tested using the method of pulling out the internet cable, but I couldn't reproduce the bug.

I tested by interrupting the internet connection from Control Panel. With this method the bug is still reproducing. This bug can be tracked on bug 1428723.

I tested with the tool Net Limiter and the bug is still reproducing. This bug can be tracked on bug 1421354. 

According to all of these results I will mark this bug as verified fixed.
See Also: → 1428723, 1421354
Flags: qe-verify+
You need to log in before you can comment on or make changes to this bug.