Closed Bug 231361 Opened 19 years ago Closed 18 years ago

download manager doesn't show downloaded filesize after 1MB if the filesize is "unknown"

Categories

(Toolkit :: Downloads API, defect, P4)

x86
All
defect

Tracking

()

RESOLVED FIXED

People

(Reporter: bisi, Assigned: bugs)

References

()

Details

(Keywords: fixed-aviary1.0)

Attachments

(5 files, 5 obsolete files)

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7a) Gecko/20040115 Firebird/0.8.0+
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7a) Gecko/20040115 Firebird/0.8.0+

For example, PHPmyadmin offers exporting of the database-files and after
choosing some properties the file begins to download, which actually has an
"unknown" size. MozillaFirebird shows the correct size till the downloaded size
reaches 1MB and then the text showing the downloaded filesize disappears
(there's only: at [speed], ??? remain).
Nevertheless the download finishes as expected and everything is OK with the
downloaded file.

Reproducible: Always

Steps to Reproduce:
1. download a file with an "unknown" filesize
2. wait till the downloaded filesize reaches 1MB
3. the downloaded filesize disappears

Actual Results:  
MozillaFirebird doesn't show the downloaded filesize after 1MB.

Expected Results:  
MozillaFirebird should show the downloaded filesize after 1MB.
Severity: minor → normal
WFM, using:

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6b) Gecko/20040102
Firebird/0.7+

I tried to download:

ftp://ftp.mozilla.org/pub/mozilla.org/firebird/nightly/latest-0.8/FirebirdSetup.exe

I watched the filesize reach 2MB/6MB no problem.

Žiga, can you post the URL you are having problems with to help further debug
your problem?
Attached image before 1MB (obsolete) —
Attached image after 1MB (obsolete) —
Yes, but the given Firebirdsetup.exe file has a known file size (ca. 6,4MB). 
I have uploaded two files, which should show, what I mean. Unfortunately I can't
give you access to my phpmyadmin, because it's password-protected for security
reasons. I'll try to find a "public" webpage, which generates files with unknown
file size.
Right. Reproduced on trunk.
Status: UNCONFIRMED → NEW
Ever confirmed: true
noririty - can you add the URL you used to reproduce the bug to the ticket
please - it will help others to reproduce the bug, and the confirm it is working
when it is fixed.
I'm sorry but I can't.
I used the password protected test case uri given by reporter to reproduce this
bug. So we need to find other test case out.
-> qawanted (test case needed)

Oh, and I also tested on 0.7 but download progress dialogbox and download
sidebar doesn't have this problem.
Keywords: qawanted
Whiteboard: test case needed
Keywords: qawanted
Whiteboard: test case needed
I have just attached an URL, which shows the bug. Click on the link "LINK" and
firebird will start downloading a 3,82MB big mpeg file (blackhumor.mpeg ;)). 

(behind the download.htm file there is, as you might see, a file called
download_mpeg.php, which "gives" the order to download blackhumor.mpeg")
I get this bug with Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7a)
Gecko/20040115 Firebird/0.8.0+
The example file is causing the code to hit the undefined state in
DownloadProgressListener._formatKBytes in DownloadProgressListener.js.

Just adding another clause to the if/elseif block to deal with this situation
seems to work OK, i.e. something like:

else if (progressHasMB && !totalHasMB) {
    // Download progress is > 1MB but filesize is unknown
    format = this._statusFormatMBMB;
    format = this._replaceInsert(format, 1, (aKBytes / 1000).toFixed(1));
    format = this._replaceInsert(format, 2, aTotalKBytes);
}
May I suggest to change the wording too? It currently says "xx of 0 KB at yy
KB/sec; ??? remain"

What about "xx KB at yy KB/s; unknown total size" or something?
I can't find the testcase link to see if this appears under Linux.
Hum, the testcase link is listed above and it works -
http://www.pikslar.com/temp/Bisi/firebird/download.htm

Benoit: this would be a nice long-term solution (like IE handling of unknown
file size downloads).
OS -> All requested, I triggered the bug on Linux.

Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7a) Gecko/20040126 Firebird/0.8.0+
(.:MrC:.)
OS: Windows 2000 → All
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7a) Gecko/20040201 Firebird/0.8.0+
(daihard: XFT+GTK2; optimized for P4/SSE-2)

Triggered it again, this time on a trunk build.
*** Bug 235614 has been marked as a duplicate of this bug. ***
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7b) Gecko/20040403 Firefox/0.8.0+
(daihard: XFT+GTK2; opt. for P4/SSE-2)

Still present, with the original testcase.
Attached patch temp fix (pike's proposal) (obsolete) — Splinter Review
I've made a temporary patch, following pike's comment, which works with my own
firefox build. I'll try to find&create a long-term solution as soon as
possible.
Attachment #146986 - Flags: review?(bugs)
Flags: blocking1.0?
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8a) Gecko/20040428 Firefox/0.8.0+
(daihard: XFT+GTK2; opt. for P4/SSE-2)

Still present, with the original testcase.

blocking1.0? indeed.
taking qa
QA Contact: aebrahim
+ing to invoke review
Flags: blocking1.0? → blocking1.0+
Attached image before 1MB (new)
Attachment #139405 - Attachment is obsolete: true
Attached image after 1MB (new)
Attachment #139406 - Attachment is obsolete: true
Attached patch patching downloads.properties (obsolete) — Splinter Review
Adding statusFormatUnknown for KB and MB, changing statusFormat (removed
"remain" after #3)...
Attachment #146986 - Attachment is obsolete: true
Changing function DownloadProgressListener (adding statusFormat for unknown
filesize in KB/MB), the "update time remaining" part of the script (adding "
remain" to the downloads with known filesize; changing ??? to unknown filesize
for the downloads with unknown filesize) and the function _formatKBytes (adding
else if for progressHasMB && !totalHasMB and changing the if [actually now it's
an else if, but that's not important] for !progressHasMB && !totalHasMB).
Attachment #147988 - Flags: review?(bugs)
Attachment #147989 - Flags: review?(bugs)
*** Bug 243775 has been marked as a duplicate of this bug. ***
Attachment #146986 - Flags: review?(bugs)
Does anyone have a rough idea of when attachments 147988 and 147989 will be
reviewed and checked in?
Status: NEW → ASSIGNED
Priority: -- → P4
*** Bug 246466 has been marked as a duplicate of this bug. ***
*** Bug 248929 has been marked as a duplicate of this bug. ***
*** Bug 250683 has been marked as a duplicate of this bug. ***
Attachment #147988 - Attachment is obsolete: true
Attachment #147988 - Flags: review?(bugs)
Attachment #147989 - Attachment is obsolete: true
Attachment #147989 - Flags: review?(bugs)
oops, forgot to set the PR blocking flag. There are also some l10n issues. I'll
try to fix those issues till tomorrow and hope I didn't miss 1.0PR...
Flags: blocking-aviary1.0PR?
any progress on this? think we need the patch this week if it is going to make PR1
Whiteboard: [have patch]
trying to shut down for PR next week. is a patch ready?  thanks
Whiteboard: [have patch] → [have patch] affects l10n
sorry for the delay, I had some problems with my motherboard. I'll upload the
patch in a few minutes...
Attached patch patchSplinter Review
all in one...
Attachment #156697 - Flags: review?(bugs)
Comment on attachment 156697 [details] [diff] [review]
patch

r+a=ben@mozilla.org, we need to get this in now for l10n freeze.
Attachment #156697 - Flags: review?(bugs)
Attachment #156697 - Flags: review+
Attachment #156697 - Flags: approval-aviary+
Flags: blocking-aviary1.0PR? → blocking-aviary1.0PR+
Could somebody check this in (I don't have a cvs account)? 

Thanks Ben!
mconnor checked in the patch to the aviary branch...
Keywords: fixed-aviary1.0
(In reply to comment #38)
> mconnor checked in the patch to the aviary branch...

If the filesize reaches 2^32 * 1024 bytes it will start counting backwards from
minus something..  at -xx kb/sec which looks very odd, i'll attach a picture
that has the file from my explorer imposed on top, sorry for the bad edit, i'm
sure you'll see what i mean..

Not sure if I should create a new bug for this ?
(In reply to comment #40)
> Created an attachment (id=165125)
> displays firefox's behaviour downloading files >2GiB
> 

>2GB case is bug 228968.
Keywords: aviary-landing
Flags: blocking-aviary1.1?
according to lxr, the code is there, can anyone reproduce on a current trunk build?
(In reply to comment #42)
> according to lxr, the code is there, can anyone reproduce on a current trunk
build?

WFM
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8b) Gecko/20050115 Firefox/1.0+
Yep, the code was checked in, however there is a bug, that I (and some people at
m'zine) discovered recently... If the file is smaller than 1MB (1024KB) and the
filesize is known, we get something like "xx KB at yy KB/s; zz remain" (the
expected line should say "xx KB of xx KB at yy KB/s; zz remain"). I'll make the
patch tomorrow and I think we don't need a new bug fo that.
Keywords: aviary-landing
Whiteboard: [have patch] affects l10n → see comment 44
Version: unspecified → Trunk
Attached patch KB fixSplinter Review
The patch fixes the small regression while downloading files smaller than 1MB.
Asking for review... It's a simple fix, so it could also get the aviary1.0.1
approval, but let's wait for the review.
Attachment #172093 - Flags: review?(bugs)
*** Bug 252547 has been marked as a duplicate of this bug. ***
Flags: blocking-aviary1.1? → blocking-aviary1.1+
*** Bug 259995 has been marked as a duplicate of this bug. ***
Whiteboard: see comment 44 → see comment 44 [checkin-needed]
I can check this in if noone else want.
(In reply to comment #49)
> I can check this in if noone else want.

I have already contacted Mike over irc and he said he would check in the "KB
fix" patch... Maybe he didn't have time to get to this bug, so feel free to
check in the last patch.
Thanks to Ben, Mike and Zbigniew!

-> fixed.
Status: ASSIGNED → RESOLVED
Closed: 18 years ago
Resolution: --- → FIXED
Whiteboard: see comment 44 [checkin-needed]
Product: Firefox → Toolkit
You need to log in before you can comment on or make changes to this bug.