274987 - Remaining download time and download speed are _badly_ estimated if I don't choose "Save As" fast

Status: RESOLVED DUPLICATE of bug 245725

(Toolkit :: Downloads API, defect)

Description

[netrix]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.5) Gecko/20041107 Firefox/1.0
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.5) Gecko/20041107 Firefox/1.0

Problem 1: If you click a file that's to be handled by the Download Manager
(Open With / Save As) and wait a long time before choosing one of these
(delaying the appearance of the Download Manager Window), the download speed
amazingly increases.
Example: Once I was "busy" on IRC and it showed 16.7 KBytes/sec - decreasing -
but I'm on dial-up and it's practically impossible for me to get over 54 kbits/sec.
Possible miscode: When calculating the average speed you're dividing SIZE/TIME,
where SIZE = current downloaded bytes and TIME = time it took to download it.
The files start downloading right after you click on them but this formula takes
into account that it's started downloading after you choose the way to deal with
it (Open With / Save As). The exact same bug was in IE 5.5 (dunno about others,
I switched to Mozilla a long time ago). This also affects Estimated Time Remaining.

Problem 2: When downloading multiple files, it's a complete mess, I can't make
up anything of the estimated % downloaded, it appears to be random.

Reproducible: Always

Steps to Reproduce:
1. Find a file that takes you 5 minutes to download
2. Click on a link to it, choose Save As and wait for the download to be completed
3. Click on it's link again, wait 4 minutes, choose Save As and wait for the
download to be completed
Actual Results:  
If in step 2 your average download speed was 100 KBytes/sec, in step 3 it's
going to be 500 KBytes/sec, even if it's physically impossible. This also
affects Estimated Time Remaining. Then, the download speed starts to decrease.

Expected Results:  
Both should have shown about 100 KBytes/sec and estimate the same ammount of time.

Comment 1

[Mike Kowalski]

*** This bug has been marked as a duplicate of 245725 ***