Please report any other irregularities here.
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:22.214.171.124) Gecko/20071128 Iceweasel/126.96.36.199 (Debian-188.8.131.52-1) Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:184.108.40.206) Gecko/20071128 Iceweasel/220.127.116.11 (Debian-18.104.22.168-1) 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?
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.
You need to log in before you can comment on or make changes to this bug.