If you think a bug might affect users in the 57 release, please set the correct tracking and status flags for Release Management.

Downloads report the wrong size when finished

VERIFIED FIXED in mozilla1.9beta1

Status

()

Toolkit
Downloads API
VERIFIED FIXED
10 years ago
5 years ago

People

(Reporter: Mardak, Assigned: Mardak)

Tracking

Trunk
mozilla1.9beta1
Points:
---
Bug Flags:
in-testsuite +
in-litmus +

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment)

(Assignee)

Description

10 years ago
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.
(Assignee)

Comment 1

10 years ago
Created attachment 283083 [details] [diff] [review]
v1
Assignee: nobody → edilee
Status: NEW → ASSIGNED
Attachment #283083 - Flags: review?(comrade693+bmo)
Comment on attachment 283083 [details] [diff] [review]
v1

r=sdwilsh
Attachment #283083 - Flags: review?(comrade693+bmo)
Attachment #283083 - Flags: review+
Attachment #283083 - Flags: approval1.9?
Flags: in-litmus?

Updated

10 years ago
Attachment #283083 - Flags: approval1.9? → approval1.9+
(Assignee)

Comment 3

10 years ago
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
Status: ASSIGNED → RESOLVED
Last Resolved: 10 years ago
Resolution: --- → FIXED
Target Milestone: --- → Firefox 3 M9
(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+ ?

(Assignee)

Comment 5

10 years ago
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.
Flags: in-testsuite+
https://litmus.mozilla.org/show_test.cgi?id=5032
Flags: in-litmus? → in-litmus+
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.
Status: RESOLVED → VERIFIED
Product: Firefox → Toolkit

Comment 8

5 years ago
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?

Comment 10

5 years ago
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...
You need to log in before you can comment on or make changes to this bug.