529038 - The "Software Update" window has wildly wrong estimated completion time

Status: RESOLVED WORKSFORME

(SeaMonkey :: General, defect)

Description

[Bill Davidsen]

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.6pre) Gecko/20091114 NOT Firefox/3.5.3 SeaMonkey/2.0.1pre
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.6pre) Gecko/20091114 NOT Firefox/3.5.3 SeaMonkey/2.0.1pre

When an update becomes available, a "Software Update" window pops open. When/if the user clicks "install update" an estimated time to completion is displayed, counting down. Unfortunately this is based on the time between NOW and the time the pop-up opened, which can be days, rather than NOW and the time when the user clicked the update button. Annoying, misleading, and saw one user look at 40 hour estimated completion time and kill the update.

Reproducible: Always

Steps to Reproduce:
1.start SeaMonkey
2.go away until the update window opens
3.go away for another few days
4.click [update] button
Actual Results:  
Estimated download to end far in the future (up to weeks) not useful and misleading to user

Expected Results:  
Estimated completion in a minute or so.

Resetting the start time after the click rather than before should take moving one line of code.

Comment 1

[Serge Gautherie (:sgautherie)]

Can you reproduce with Firefox v3.5.8?

Comment 2

[Bill Davidsen]

I suppose I could, but since I don't use Firefox and have no way to trigger a Firefox update, it might take weeks or months. Since the behavior requires having the browser open both before the update is issued and for some time after, it's not really convenient to have some machine up with a login and Firefox active, and then leave them for as many days or weeks as it takes for the next update to be pushed, wait a day or so after that and then click the update button.

What could be done in a few minutes is to look at where the "transfer starting time" is saved, and verify that it is before the user click update, rather than after, when the transfer actually starts.

Comment 3

[lenochod]

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.3a4pre) Gecko/20100319 SeaMonkey/2.1a1pre
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.8) Gecko/20100205 SeaMonkey/2.0.3

I didn't found any time stamp in 'Software Update' processes. 

Can you try and reproduce with SeaMonkey v2.0.3 ?

Please, give more detailed steps to reproduce. Found it during download, or during upgrade, etc.?

Comment 4

[Bill Davidsen]

I reviewed the steps to reproduce and they look right, left me try saying it in text.

The issue arises when the SM process is active and an update becomes available. This causes an "update available pop-up to appear" which may be on a desktop where it is not visible, or may happen when the user is away. Our servers have the mail window open for days at a time to track issues via RSS.

When the user finally clicks the [UPDATE] button and the file transfer starts, the progress reporter gives an estimated time of completion. It does this by calculating transfer speed, using the bytes transferred and the elapsed time. The problem is that the elapsed time is wrong, instead of being the current time minus the start of transfer time, it appears to be the current time minus the time when the pop-up was generated (which may be several days ago). This results in a VERY long "time remaining" being shown and users deciding they don't want to wait hours and abort the update.

I have confirmed this as probable, by clicking the [UPDATE] immediately and getting correct results, after an hour and seeing time remaining appear to match a transfer starting then, and coming in on Monday and seeing an update waiting, which had an appropriately long estimated time to completion.

Not an issue for admins who ignore that, but training users is like herding cats, they have their way of doing things when the admin isn't looking.

Comment 5

[Mike H.]

I just had this happen for me when upgrading Thunderbird to:
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.8) Gecko/20100802 Lightning/1.0b2 Thunderbird/3.1.2

I believe I had Thunderbird 3.0.6 before the upgrade.  The upgrade window must have been open for quite a while, because the initial download estimate was over a week.  The download completed in about a minute, and the reported transfer speed made it up to just over 200 bytes per second.

Comment 6

[Phoenix]

Is this still reproducible with latest build?

Comment 7

[Bill Davidsen]

I'll see if I can reproduce, changes to either the options I choose or the process used have kept me from seeing it recently. However, the code to display the remaining time to download must use bytes done and a starting time, that starting time is the issue. It should be set when the user chooses the YES response, the original report behaved as though the starting time was set when the pop-up was opened.

I'll take a quick check to see if I can reproduce.

Comment 8

[Bill Davidsen]

The update notification haws changed enough that I can't readily test this or reproduce it. If I see it again in a form I can reproduce I'll refile, the moment has passed.

Comment 9

[Phoenix]

Tested with 2.5b4 update, opened update window, hibernate pc for a couple of days, after resuming started update - download time was correct