06-28 build OS 10.1.5 1. Go to ftp://ftp.mozilla.org/pub/chimera/nightly/latest-trunk/. 2. Right click on chimera.dmg.gz and click "Save Link As" to save file to desktop. 3. Download status dialog shows up. When download completed, the dialog says "6.4 MB of 6.4 MB total (at 3.2 MB/sec) Elapsed time: 00:02" 4. Click "Show Info" on the downloaded file on desktop. It says that the file is 6.7MB on disk (7,119,420 bytes) Expected result: File size displayed in download status dialog box should be the same as what's shown in "Show Info". Actual result: File sizes are different - 6.4MB vs. 6.7 MB. If I try steps 1-4 above several times, I get different file sizes in the download status dialog box almost every time, but consistent file size in "Show Info". These are the variou download status that I've gotten in the dialog box for downloading the same file: 6.4 MB of 6.4 MB total (at 3.2 MB/sec) Elapsed time: 00:02 6.7 MB of 6.7 MB total (at 2.2 MB/sec) Elapsed time: 00:03 6.7 MB of 6.7 MB total (at 3.3 MB/sec) Elapsed time: 00:03 6.4 MB of 6.4 MB total (at 2.1 MB/sec) Elapsed time: 00:03 6.3 MB of 6.3 MB total (at 1.6 MB/sec) Elapsed time: 00:04 It seems like the download status dialog box is calculating file size by multiplying the download speed by the elapsed time.

I can't replicate this. Using 6/29 NB & up-to-the-minute CVS build, looking at the provided link (which at this time, the website says is a 6953 kb download), I'm consistently getting the download progress indicator to show file size of 6.8 MB, which is what it should be. The calculation in this window is based on what nsDownloadListener reports the file size to be - it's definately not download speed * time. in nsDownloadListener::onProgressChange, chimera thinks the file has 7119657 bytes. The finder "get info" window also thinks the file has 7119657 bytes. Chimera calculates 7119657 bytes as 6952.7 kb in size, or 6.78 MB in size. (7119657/1024 = 6952.7/1024 = 6.78), which it rounds up to 6.8. Similar calcs show 7119420 should be 6.8 also. Why the finder doesn't round up is beyond me - I think it's a bug on Apple's part.

Maybe this only happens with really fast local downloads.

i'm wondering if this might be affected by the annoying "start predownloading before the user selects target location" feature. see bug 55690 (and bug 129923) for the gorey details.

This may also happen if the download was previously started, then cancelled. In that case we can start off with some cached data, that might throw the file sizes off.

i have seen this myself, usually with a restarted d/l. not sure if it's really that big of a deal.

I get this very same problem on WinXP with Firefox. I have clean install with clean profile and still the same thing. It happens every time I download something for the last few month and with small files the difference in filesize is quite miniscule, but with larger downloads it becomes more and more obvious. e.g. I tried downloading from this site: http://download.beyondunreal.com/fileworks.php/mods/fragops-v138setup.exe Real size: 348.62 MB Size reported by Firefox: 357MB Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7) Gecko/20040709 Firefox/0.9.0+

*** Bug 175453 has been marked as a duplicate of this bug. ***

Someone check if this is still true? I haven't seen it, personally.

Updating link.

This WORKSFORME. Can anyone still reproduce this? It's been dead for a while and I can't.

I'm not able to reproduce this, either--neither comment 0 nor comment 4. I suppose it's possible something on the trunk fixed it, or maybe Simon's fix that had something to do with un-corrupting MP3 downloads or Mark's fixing of the large file size bug.... Simon, Mike, do you still see this?

WFM too, even on previously-cancelled download.