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

Status: VERIFIED FIXED

(Firefox :: Installer, defect, P1)

Description

[Jason Smith [:jsmith]]

Steps:

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

Expected:

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.

Actual:

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?

Comment 1

[Robert Strong (they/them - no direct email)]

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.

Comment 4

[Molly Howell (she/her) (no longer active)]

Gonna try to get this in for 58.

Comment 5

[Molly Howell (she/her) (no longer active)]

Attachment: Bug 798005 - Resume interrupted downloads in the stub installer, instead of starting over.

Review commit: https://reviewboard.mozilla.org/r/186898/diff/#index_header
See other reviews: https://reviewboard.mozilla.org/r/186898/

Comment 6

[Molly Howell (she/her) (no longer active)]

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 7

[Molly Howell (she/her) (no longer active)]

Comment on attachment 8915693 [details]
Bug 798005 - Resume interrupted downloads in the stub installer, instead of starting over.

Review request updated; see interdiff: https://reviewboard.mozilla.org/r/186898/diff/1-2/

Comment 8

[Molly Howell (she/her) (no longer active)]

Comment on attachment 8915693 [details]
Bug 798005 - Resume interrupted downloads in the stub installer, instead of starting over.

Review request updated; see interdiff: https://reviewboard.mozilla.org/r/186898/diff/2-3/

Comment 9

[Adam Gashlin (he/him) [:agashlin] (ex-moco)]

Comment on attachment 8915693 [details]
Bug 798005 - Resume interrupted downloads in the stub installer, instead of starting over.

https://reviewboard.mozilla.org/r/186898/#review193236

Comment 10

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/f5fcec1a1c2d
Resume interrupted downloads in the stub installer, instead of starting over. r=agashlin

Comment 11

[Sebastian Hengst [:aryx] (needinfo me if it's about an intermittent or backout)]

https://hg.mozilla.org/mozilla-central/rev/f5fcec1a1c2d

Comment 12

[u554753]

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?

Comment 13

[Molly Howell (she/her) (no longer active)]

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.

Comment 14

[u554753]

As of today's Nightly, I'm seeing the behavior in Comment 12 when dealing with the Stub Installer. Are you seeing this issue?

Comment 15

[Molly Howell (she/her) (no longer active)]

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.

Comment 16

[Oana Botisan, Desktop QA]

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.

Comment 17

[Molly Howell (she/her) (no longer active)]

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.

Comment 18

[Oana Botisan, Desktop QA]

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.

Comment 19

[Molly Howell (she/her) (no longer active)]

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.

Thanks!

Comment 20

[Oana Botisan, Desktop QA]

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.