The wrong size gets reported because ProgressChange64 doesn't always get called -- especially at the end of the download, so the reported file size (if it was shown in the UI or stored in the DB) would be slightly short. This will get fixed by bug 394548, but I'll add the testcase for this specific bug. Depending on how the patches land, the UI might never show this problem, but there can still be a litmus testcase to make sure the displayed file size is correct.. easier to test with sub KB file sizes as those are likely to miss the ProgressChange updates and report 0 if bug 394548 wasn't fixed.
Created attachment 283083 [details] [diff] [review] v1
Comment on attachment 283083 [details] [diff] [review] v1 r=sdwilsh
Checking in toolkit/components/downloads/test/unit/test_resume.js; /cvsroot/mozilla/toolkit/components/downloads/test/unit/test_resume.js,v <-- test_resume.js new revision: 1.2; previous revision: 1.1 done
(In reply to comment #3) > Checking in toolkit/components/downloads/test/unit/test_resume.js; > /cvsroot/mozilla/toolkit/components/downloads/test/unit/test_resume.js,v <-- > test_resume.js > new revision: 1.2; previous revision: 1.1 > done Doesn't that mean that we can add in-testsuite+ ?
Ah right. The litmus testcase would only really work later on when we display the size of the download in the UI. So something like... 1) Load data:text/plain,Hello World! 2) Save page 3) Ensure that the size is however many bytes it should be.
Verified FIXED using: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.4; en-US; rv:1.9b3pre) Gecko/2008012504 Minefield/3.0b3pre Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9b3pre) Gecko/2008012504 Minefield/3.0b3pre -and- Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9b3pre) Gecko/2008012504 Minefield/3.0b3pre "data:text/plain,Hello World!" correctly saves as 12 bytes.
you can re-open this bug. it's been a problem since version 4 or so. I have been meaning to report it, but it is about time I did. so please fix. the download size firefox seems to get is reported wrong. so it ends up cutting the file short. this happens randomly. not sure what causes this. ISP: comcast maybe the packets just get dropped or mangled? so be sure tocheck the CRC/checksum of the packets. but if it's not amangling problem, then something else is going on, maybe a flaky logical bug. pour through the download code where file sizes are calculated, and look for the possibility of any uninitialized variables. that could be a source of flakiness. I think the code for downloading is fine, just the part where the size is calculated is wonky.
(In reply to Jim Michaels from comment #8) > you can re-open this bug. it's been a problem since version 4 or so. I have > been meaning to report it, but it is about time I did. so please fix. Could you please file your own bug report with good information and steps to reproduce instead of trying to reopen a 2008 bug about something else?
I am doing just what everyone tells me to - to use existing bug reports! I wasn't expecting rebuke for doing the right thing. I guess I will have to use a different title too...