Closed Bug 84410 Opened 23 years ago Closed 23 years ago

downloading file with unknown size reports NaN% complete, negative time left and no progress bar


(SeaMonkey :: UI Design, defect, P3)



(Not tracked)



(Reporter: glob, Assigned: mscott)




(Whiteboard: [nsbranch+,pdt+])


(9 files)

From Bugzilla Helper:
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9+) Gecko/20010602
BuildID:    2001060220

downloading a file from a location that doesn't report the correct size produces
a few odd things with the progress dialog.

the status is reported as:  ###K of 0K bytes
i think that is the size isn't know, the "of 0K bytes" should not be displayed.

also, the process bar is always empty, with the percentage always displayed as
NaN%.  again, i think that if you can't determine the file size, you shouldn't
display the process bar.

Reproducible: Always
Steps to Reproduce:
you'll get this if you're downloading a file that is the output of a cgi.

there's 5 meg waiting for you at
Related to bug 70859?
WFM. With 2001060820 Win2k, I'm seeing:

Status:    ### of ??K bytes (at ##.##K bytes/sec)

... and a spinning progress bar.
Could you retry with a new build?
just tried with 2001060920 and i'm still seeing the problem.

i've got a screenshot of it at
(sorry - i don't know how to attach it to this bug)

also notice the time left counter is 00:0-14 in this screenshot (ie it's a
negative time).

i see this using branch bits on linux [2001.06.07.13] and mac [2001.06.07.11];
also occurs with both themes. will attach screenshots.
Assignee: blakeross → law
Blocks: 78106
Ever confirmed: true
Keywords: mozilla0.9.2, ui
OS: Windows 2000 → All
Hardware: PC → All
Summary: downloading file with unknown size reports NaN% complete → downloading file with unknown size reports NaN% complete, negative time left and no progress bar
bumping up to normal...doesn't seem trivial, imho :).
Severity: trivial → normal
*** Bug 82702 has been marked as a duplicate of this bug. ***
nav triage team:

Need to fix this eventually, but won't get around to it before mozilla1.0.
Marking nsbeta1+, p3, and mozilla1.0
Keywords: nsbeta1+
Priority: -- → P3
Target Milestone: --- → mozilla1.0
since I get this on
I don't think it's restricted to files of unknown size.  The size is 
known & right there on the page  

->mscott or blake...not sure if either of you have cycles for this one [true, it
has been marked moz1.0 --couldn't hurt to ask].
Assignee: law → mscott
*** Bug 87852 has been marked as a duplicate of this bug. ***
*** Bug 87785 has been marked as a duplicate of this bug. ***
Ben: I can't reproduce on
(with 0.9.1)

Which version are you seeing this -- maybe a regression?

Also be sure that no proxies doing filtering are in-between.

I only see this problem when DLing via proxy.

at home via dialup generic ISP, the saving file statistics are AOK using the 
very same build I used at work for my last test.  home is 98 vs NT at work, 
direct connection vs firewall/proxy

I think I've been seeing this through the proxy for at least a week.  I have an 
older screen capture of the saving file box at work, I'll check the create date 
on that as soon as I get in


I show this as early as 6/18.  I dl the latest at least once or twice a day & my 
time stamp is 11:51 EDT, so I was probably using a build from the day before.

bug 87852 which is a dupe of this one was my report & has more details specific 
to my case

I'm seeing this in 2001070204 Win98.
Just created bug 89113 for the proxy problem.
Attached patch the fixSplinter Review
I've attached the fix. Please note the one line DTD change so we can actually
show the word "Unknown" in the time left field. If we try to get this into rtm,
we'll have to get localization to approve this dtd change. 

nominating for the branch.
Keywords: nsbeta1+nsbeta1, nsBranch
Target Milestone: mozilla1.0 → mozilla0.9.3
*** Bug 87327 has been marked as a duplicate of this bug. ***
this very low risk fix has been checked into the trunk. Adding the vtrunk
keyword. I'm hoping this can make it into a nsbranch+ state due to the low risk. 
Keywords: vtrunk
tested using a 21:23 debug trunk build on linux: definitely an improvement, but
the "0K bytes" in the Status is still there while download is in progress...any
way to easily change that string to "Unknown" as well?

however, when download is finished, the Status does redraw to display the total
elapsed time.

screenshots coming up.
erm, i meant: s/went/when in the attachment comment.
*** Bug 87327 has been marked as a duplicate of this bug. ***
Whiteboard: [nsbranch+]
verified fixed using 2001.07.05.0x-trunk comm bits on mac, linux and winNT
--except for the "0K bytes" issue noted above. [let me know whether we're going
to stay with that for now.]
When the branch is open, please check this into it today after getting
permission to add the new string.
Whiteboard: [nsbranch+] → [nsbranch+,pdt+]
fixed on the branch.
Closed: 23 years ago
Resolution: --- → FIXED
removing vtrunk since i had already vrfy'd it there on 2001-07-05 13:51.
verified fixed on the branch using the following comm branch builds:

linux 2001.07.09.04
winnt 2001.07.09.05
mac 2001.07.09.03

filed bug 90074 to fix the "OK bytes" Status string while download is in
Keywords: vtrunk
do we need to file a seperate bug to address the issue of why it is unknown when
through a proxy, but known otherwise?

DLing the latest Mozilla is a classic example.  at home via dailup I get a %
completion & the size is known.  at work, via a proxy, the size is "unknown" 
ben, it'd prolly be best to file a separate bug on that in the Networking
ben see bug 89113 for the proxy problem

*** Bug 90602 has been marked as a duplicate of this bug. ***
*** Bug 92149 has been marked as a duplicate of this bug. ***
Product: Core → Mozilla Application Suite
Component: XP Apps: GUI Features → UI Design
You need to log in before you can comment on or make changes to this bug.