304381 - Hiding update window while downloading updates causes very slow (seemingly stopped) download

Status: RESOLVED FIXED

(Toolkit :: Application Update, defect)

Description

[Ben Turner (not reading bugmail, use the needinfo flag!)]

Clicking on the "Hide" button of the software update window works as expected. 
If you are downloading updates when you click the button, however, the menu 
item that once said "Check for Updates..." now says "Downloading Deer Park 
1.0+" and has a spinning download icon next to it. This gives the impression 
that the download is proceeding in the background. The download will never 
complete, however, because the download has actually been paused. TCP 
monitoring tools confirm that no information is sent or received until you 
click on that menu item and the download resumes.

Which is the desired approach? To pause the download? Or to continue the 
download in the background? If we're going for the former then the icon should 
definitely not be moving and the text should say something about resuming. If 
we're going for the latter then we need to continue the download.

I'm using the 2005-08-09 build with app.update.url="https://aus-
staging.mozilla.org:8711/update2/0/%PRODUCT%/%VERSION%/%BUILD_ID%/%
BUILD_TARGET%/%LOCALE%/update.xml"

Comment 1

[Darin Fisher]

-> beng

Comment 2

[Darin Fisher]

I can repro this also.  I think we should fix this for beta.

Comment 3

[Ben Turner (not reading bugmail, use the needinfo flag!)]

You can also get this to happen by doing the following:

Begin the update, click "Pause", then click the "Hide" button. This time a 
message box will pop up asking if you want to continue the download in the 
background. You can click yes, but nothing actually gets downloaded as before.

Comment 4

[Ben Turner (not reading bugmail, use the needinfo flag!)]

The misleading menu item also persists through a restart of FireFox if the 
download is never completed...

Comment 5

[Darin Fisher]

> Begin the update, click "Pause", then click the "Hide" button. This time a 
> message box will pop up asking if you want to continue the download in the 
> background. You can click yes, but nothing actually gets downloaded as before.

Are you sure?  The browser will periodically issue byte-range requests in this
case, but it will only do so once every 60 seconds.

Comment 6

[Darin Fisher]

Actually, this bug is WORKSFORME.  Just wait 60 seconds, and you'll observe that
Firefox fetches the next chunk of the update archive.

Comment 7

[Ben Turner (not reading bugmail, use the needinfo flag!)]

> Are you sure?  The browser will periodically issue byte-range requests in
> this case, but it will only do so once every 60 seconds.

I agree that firefox is doing something... but I have no idea what. My 
internet connection downloads the update in about fifteen seconds with the 
window displayed, but has sat for over five minute with the window hidden. The 
packet monitor is showing activity about every fifteen seconds or so, but 
nothing for any noticeable duration.

Comment 8

[Darin Fisher]

It's designed to download a complete update in about an hour and half.  The idea
is to not overburden the update service.  We'll probably end up tweaking the
parameters a bit over time, but for now it is set to something conservative.

Perhaps it would make sense to not go into slow mode when the user merely hides
the dialog.  Hmm...

Comment 9

[Ben Turner (not reading bugmail, use the needinfo flag!)]

Discussed this with Darin today and we both agreed that this isn't really the 
right solution to the underlying problem.

There are two upload modes right now: silent and explicit. Silent mode 
requires no user interaction and goes very slowly to make sure that the update 
servers are not hit too hard. Explicit mode downloads at full speed in it's 
own window. The real problem is that there are a few different ways that users 
interact with the update service and our mode selection is counterintuitive in 
some cases. 

Silent mode seems suited only for the case where an update is available and 
the user never knows that it's being downloaded. They don't need to be tipped 
off until the download has completed, and so it can go as slow as necessary. 
Also, if a download is cut off because of a restart then it seems fine to 
resume the download in silent mode. Once a user is aware that an update is 
downloading, however, it seems logical to assume that the user is also waiting 
for it to complete. Once the user has interacted with the update in any way 
then the speed needs to increase back to normal to reduce the wait time. 

To summarize several cases and proposed download modes:

1. User has no knowledge of update => Silent
2. Download is cut off due to a restart and then resumes without user 
interaction => Silent
3. Silent update begins, then user clicks on the update menu item => Explicit
4. User requests update and then hides the update window => Explicit
5. User requests update and leaves update wizard visible => Explicit

Right now case 4 is running in silent mode, which seems counterintuitive and 
may lead the user to think that the download has stopped (this certainly 
fooled me the first time I ran into it!). 

Comment 10

[Asa Dotzler [:asa]]

I don't think this is a critical problem with update. If you all come up with a
safe solution, either a change in the wording or the behavior, please request
approval for the branch. 

Comment 11

[Ben Turner (not reading bugmail, use the needinfo flag!)]

Attachment: patch to fix scenario 4 (comment #9) to use explicit mode

This is a simple fix... I haven't seen any bad behavior yet, but I wonder...
Can the solution really be this easy?

Comment 12

[Darin Fisher]

Comment on attachment 197232 [details] [diff] [review]
patch to fix scenario 4 (comment #9) to use explicit mode

>Index: content/updates.js
...
>+      // Continue download in the background at full speed.
>+      LOG("UI:DownloadingPage", "onWizardCancel: continuing download in background");
>+      //updates.pauseDownload();
>+      updates.downloadUpdate(gUpdates.update, false);

nit:  commented out code generally sucks.  better to remove it or if
you need to keep it around, comment why it's being left around.  in
this case, i think you can just remove it.

I asked BenG to take a look at this patch too.	I want to get his approval
on this design since it is a change from the original.

Comment 13

[Ben Turner (not reading bugmail, use the needinfo flag!)]

Updating summary and flags. Nominating for rc1 to get this back on the radar. I 
think this is a bug that has the potential to confuse lots of folks. 

Comment 14

[Asa Dotzler [:asa]]

weeks have elapsed with no comment from ben and no patch to make this change. it
doesn't look like this is going to make it for 1.5

Comment 15

[Asa Dotzler [:asa]]

we can revisit this design issue later. not a  blocker.

Comment 16

[Ben Goodger (use ben at mozilla dot org for email)]

This is probably not the worst thing that ever happened, although I can see how
you'd argue it's a bug. I agree with the - for now since we're in lockdown. 

Comment 17

[Mike Connor [:mconnor]]

Plus to get on radar for rethink.  My thoughts are that Ben T is probably right, though I see why it was implemented the way it was.

Comment 18

[Mike Beltzner [:beltzner, not reading bugmail]]

Yeah, Ben T's got the right analysis and recommendation here. As soon as a user is *aware* of an update, they'll be (at some concious level) waiting for it to complete, so we should expedite that process.

Comment 19

[Mike Connor [:mconnor]]

Jeff, can you test out the patch here and re-request reviews as appropriate?

Comment 20

[Jeff Walden [:Waldo]]

Attachment: Patch

The previous patch was the right patch, and this patch effectively duplicates the part of it that matters (addressing review comments).  The next comment will explain why the second part of the patch has been omitted, with an illustrative screenshot.

Comment 21

[Jeff Walden [:Waldo]]

Attachment: Screenshot of change introduced by omitted part of original patch

The second change in the original patch apparently was intended to show a prettier final wizard page after an update was explicitly installed; the results are displayed in the attachment.  To get to this difference, all you'd have to do is explicitly check for updates, leaving the updater unhidden the entire time, and wait for full download.  The left Firefox is an unmodified 1.5 tarball; the right is one modified to include the extra chunk of the original patch.

While the patched Firefox is considerably more informative than the unpatched Firefox, note that the flavor text is slightly off from what it should be -- it's clearly oriented too much toward the background download case and not toward a foreground download.  I think it would be better to have a final update page which is more like the one on the right (in terms of being more informative) as part of bug 340156, and I don't want to introduce slightly subpar UI here if only the first chunk in the patch is actually necessary to fix this bug.

Comment 22

[Ben Turner (not reading bugmail, use the needinfo flag!)]

(In reply to comment #21)
 informative) as part of bug 340156, and I don't want to introduce slightly
> subpar UI here if only the first chunk in the patch is actually necessary to
> fix this bug.

Sounds good to me.

Comment 23

[Jeff Walden [:Waldo]]

Patch in on trunk a week or so ago and in on branch just now.