bugzilla.mozilla.org has resumed normal operation. Attachments prior to 2014 will be unavailable for a few days. This is tracked in Bug 1475801.
Please report any other irregularities here.

Negative (0-12:0-42) time remaining when the file is bigger than the size announced by the HTTP server




Downloads API
11 years ago
10 years ago


(Reporter: Sabrina Dubroca, Unassigned)


Firefox Tracking Flags

(Not tracked)




11 years ago
User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv: Gecko/20071128 Iceweasel/ (Debian-
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv: Gecko/20071128 Iceweasel/ (Debian-

When downloading a file on a server which announces a size smaller than the actual size of the file, a negative "time remaining" is displayed

Reproducible: Didn't try

Steps to Reproduce:
1. start downloading a file from a server announcing a wrong size
2. download more than the announced size
Actual Results:  
"53 of 49.2 MB at 4.4 KB/sec; 0-13:0-36 remain" text shown under the download progress bar

Expected Results:  
Maybe announce an "unknown time remaining"
I need one of two things from you:
1) The url to a server which does this
2) Does this happen in an official build (aka, not iceweasle)

biesi - how common do you think it is for a server to send us the wrong size, and should we even care?

Comment 2

10 years ago
Shawn, I think this is part of a larger problem. 

It seems like the downloads manager's progress monitor non-gracefully handles the downloading of some compressed files like ".gz" files when the browser does the decompression automatically. For example, try downloading some of the ".ps" and ".pdf" files from this site ( http://xxx.lanl.gov/list/astro-ph/new ) and watch the progress monitor in the downloads manager. The site sends the file in compressed format as can be confirm by looking at the http headers. The progress monitor, however, increments until it reaches the uncompressed size but says it is "out of" the compressed size. This is ratio is larger than one and therefore confuses the user. It also looks like the uncompressed file was transfered rather than the compressed file. Opera seems to suffer from a similar problem.

The original poster more likely ran into the situation I described above than an actual incorrect content-length http header. The later case is a server-side problem, not a browser problem, and I would argue that a work-a-round should not be created anyway.
That would likely be a network bug then, and not one with the download manager.


10 years ago
Product: Firefox → Toolkit
You need to log in before you can comment on or make changes to this bug.