260741 - Wrong download file size in MB is reported

Status: RESOLVED FIXED

(Toolkit :: Downloads API, defect, P5)

Description

[Mike W]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8a4) Gecko/20040920 Firefox/0.9.1+
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8a4) Gecko/20040920 Firefox/0.9.1+

When downloading a file of 19631008 bytes i.e. 18.72MB (from
http://www.nero.com/en/download_previous.php?vpak=1) the download status shows
X.X of 19.2 MB at YY.Y KB/sec. 
After download the files size downloaded was checked and reported by windows as
19631008 bytes 18.7 MB. It seems like a factor of 1.024 is missing, i.e. KB has
been divided by 1000 for MB instead of 1024.
19631008 bytes = 19171 KB (divided by 1024, as reported by Mozilla)
19171KB = 18.72MB (divided by 1024 as reported by Windows, and the Nero download
site)

If you intend using MB as 1000KB and not 1024 KB then suggest leaving the size
reported in KB as in Mozilla to avoid the problem.

Reproducible: Always
Steps to Reproduce:
1. Download file from URL above and compare reported size in MB with actual size
in KB /1024
2.
3.

Actual Results:  
Reported MB as KB/1000

Expected Results:  
Reported MB as KB/1024

Compared with Mozilla nightly which shows download in KB and not in MB

Comment 1

[Mike W]

Attachment: Small crop of screenshot showing differences in sizes

Comment 2

[Mike W]

See also  http://www.romulus2.com/articles/guides/misc/bitsbytes.shtml about use
of 1000 and 1024. I think either 1000 or 1024 should be used consistently both
for KB and MB depending on use of decimal or binary systems, and not a mix of
1024 for calculating KB and then 1000 for calculating MB.

Comment 3

[Phil Ringnalda (:philor)]

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

Comment 4

[:Gavin Sharp [email: [e-mail]]]

So my suggestion is to leave the "KB" as is and use 1024 as a base unit
everywhere instead of the 1024/1000 split there is now. This would be consistent
with the Windows properties dialog, and most sites I've seen use that method
when specifying download sizes.

Comment 5

[Phil Ringnalda (:philor)]

There's more than enough arguing about KiB-MiB/kB-MB in bug 65710 and bug 106618
to suit anyone's needs (especially Ben saying essentially "keep your KiB out of
Firebird" in bug 106618 comment 36): just making 1 MB 1048576 bytes instead of
1024000 and then running away seems best.

Comment 6

[:Gavin Sharp [email: [e-mail]]]

(In reply to comment #5)
> just making 1 MB 1048576 bytes instead of 1024000 and then running away seems
> best.

Agreed. This will be affected by the merging of branch and trunk. I'll wait for
that to happen before attaching a patch.

Comment 7

[:Gavin Sharp [email: [e-mail]]]

Attachment: Patch

Changes the size calculation to correspond with the way Windows and many sites
do it. Also makes files look smaller :).

Comment 8

[:Gavin Sharp [email: [e-mail]]]

Attachment: Patch 2

D'oh! Don't mess with timer stuff...

Comment 9

[Mike Connor [:mconnor]]

Comment on attachment 167910 [details] [diff] [review]
Patch 2

diff -up8 please, in the future, provides much more context, and the current
function name for js/c++

Comment 10

[Jerry Baker]

So the filesize will be based on 1024, but the download rate will be based on
1000? Seems strange to me.

Comment 11

[:Gavin Sharp [email: [e-mail]]]

Attachment: Patch 3

(In reply to comment #10)
> So the filesize will be based on 1024, but the download rate will be based on

> 1000? Seems strange to me.

Oops.

Comment 12

[:Gavin Sharp [email: [e-mail]]]

Comment on attachment 169051 [details] [diff] [review]
Patch 3

Carrying over r=mconnor

Comment 13

[Ian Neal]

Comment on attachment 169051 [details] [diff] [review]
Patch 3

Checking in
mozilla/toolkit/mozapps/downloads/content/DownloadProgressListener.js;
/cvsroot/mozilla/toolkit/mozapps/downloads/content/DownloadProgressListener.js,
v  <--	DownloadProgressListener.js
new revision: 1.7; previous revision: 1.6
done

Comment 14

[Frank Wein [:mcsmurf]]

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

Comment 15

[:Gavin Sharp [email: [e-mail]]]

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

Comment 16

[Jo Hermans]

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

Comment 17

[:Mook]

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

Comment 18

[:Gavin Sharp [email: [e-mail]]]

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