[BRANCH] Many Entries listed as 0kb of 0kb downloaded

RESOLVED FIXED in mozilla1.4beta


Download & File Handling
16 years ago
8 years ago


(Reporter: Scott MacGregor, Assigned: janv)


(Blocks: 1 bug)

Dependency tree / graph

Firefox Tracking Flags

(Not tracked)


(Whiteboard: custrtm-)


(1 attachment)



16 years ago
I'm currently running a trunk build from: 2002041503. 

I was just noticing that most of the files I've downloaded show up in the
download manager as 0kb of 0k transferred. 

It looks like for all of these files, we've actually finished downloading the
file before I've dismissed the helper app (or save to disk) dialog. Really large
files that aren't downloaded before I dismiss the save to disk / helper app
dialog seem to have the right sizes listed. It's just these in particular that
show 0k of 0kb.

Comment 1

16 years ago
Right.  We don't get begin getting notifications until the location is actually 
chosen.  I don't think this is Download Manager's fault.
Assignee: blaker → law
Component: Download Manager → File Handling
could this be due to the good ole background-loading-to-a-temp-location issue?
(bug 55690 and bug 129923)

i also see this on the branch, and on all platforms.
Blocks: 129923
Component: File Handling → Download Manager
OS: Windows 2000 → All
Hardware: PC → All
when in this state, the download manager also FAILS to show the following:

* painting the progress meter
* correct percentage (just says 0)
* displaying time remaining
* displaying time elapsed
* displaying the transfer speed
Keywords: nsbeta1

Comment 4

16 years ago
nsbeta1+/adt2 per Nav triage team, we should at least indicate what is happening
(download before user OK), even if it is the wrong thing.
Keywords: nsbeta1 → nsbeta1+
Whiteboard: [adt2]
Target Milestone: --- → mozilla1.0

Comment 5

16 years ago
Blake, did progress dialogs ever say 0 of 0?

Comment 6

16 years ago
Created attachment 82864 [details] [diff] [review]
Patch, see notes below for important additional info!

Please do not try to apply this patch!	I have extracted the pertinent addendum
to the patch previously attached to bug 129614.  The changes extracted here are
the additional changes needed to fix *this* bug.  This one should not be fixed
without fixing that one also.  However, we *could* do that (but that would
require a different patch).

I'm attaching this to explain the fix for this bug and solicit feedback.  We
will either roll this fix into that for bug 129614, or, apply that fix and then
generate a new patch on top of that for this bug.

The two additional changes for this bug are:

1. Add a call to OnProgressChange just prior to sending the STATE_STOP
OnStateChange notification.  This communicates the content length to the
appropriate web progress listeners to ensure that they know how big the
downloaded file was.  Note that this requires the change for bug 129614 because
part of that change was deferring the sending of the STATE_STOP.  Without that
change, that notification (and this OnProgressChange notification) would likely
come too early and the download manager and/or progress dialog would miss it.

2. A slight modification to the download manager so that when it converts the
content length to Kb, it doesn't round down really small files to 0Kb. 
Instead, these read as 1Kb.  That matches the size displayed in the ftp
directory listing, for example.

Comment 7

16 years ago
Great, thanks for fixing this! This bug was really annoying. I'll take a look at
the patch in bug 129614 soon for review.

Comment 8

16 years ago
*** Bug 132350 has been marked as a duplicate of this bug. ***

Comment 9

16 years ago
removing plus for retriage
Keywords: nsbeta1+ → nsbeta1

Comment 10

16 years ago
nsbeta1+/adt3 per Nav triage team.
Keywords: nsbeta1 → nsbeta1+
Whiteboard: [adt2] → [adt3]


16 years ago
Depends on: 129614

Comment 11

16 years ago

Comment 12

16 years ago
Last Resolved: 16 years ago
Keywords: adt1.0.0
Resolution: --- → FIXED


16 years ago
Whiteboard: [adt3] → [adt3 rtm]


16 years ago
Whiteboard: [adt3 rtm] → [adt3 rtm] custrtm-


16 years ago
Keywords: adt1.0.1

Comment 13

16 years ago
Mass removing adt1.0.0, and adding adt1.0.1 because, we are now on 1.0.1.
Keywords: adt1.0.0
i tested this out using today's commercial trunk bits (linux rh7.2, win2k and
mac 10.1.5), and so far this looks good. i tried saving from both the context
menu ("save link target") as well as via the helper app dlg.

however, i did find a hitch: on mac os x, i crash when saving a file with a long
name iff the download mgr is up. okay, that might be an edge case, and might not
even be related to this issue. i've filed bug 150727 for the crasher.
Whiteboard: [adt3 rtm] custrtm- → [adt3 rtm] custrtm- [verified on trunk]
really marking vrfy'd fixed [for the TRUNK].
Whiteboard: [adt3 rtm] custrtm- [verified on trunk] → [adt3 rtm] custrtm-

Comment 16

16 years ago
adding adt1.0.1+.  Please get drivers approval before checking into the branch.
Keywords: adt1.0.1 → adt1.0.1+, mozilla1.0.1


16 years ago
Attachment #82864 - Flags: approval+

Comment 17

16 years ago
please checkin to the 1.0.1 branch. once there, remove the "mozilla1.0.1+"
keyword and add the "fixed1.0.1" keyword.
Keywords: mozilla1.0.1 → mozilla1.0.1+

Comment 18

16 years ago
Bill, are you going to check this in on the branch?

Comment 19

16 years ago
Bill, can you check this into the branch? looks like you've got the drivers plus
and the adt plus. 
oddly, bug 149510 cropped up..but on 5 June 2002. could it be related to this issue?

Comment 21

15 years ago
law: was this patch checked into the branch? if yes, pls replace "mozilla1.0.1+"
with the "fixed1.0.1" keyword.

Comment 22

15 years ago
adt1.0.1- per the ADT. let's get it in the next release.
Keywords: adt1.0.1+ → adt1.0.1-
re-opening and retargeting for 1.0.2.
Please ask for approval for 1.0.2 when it opens.
Removing mozilla1.0.1+
Keywords: mozilla1.0.1+
Summary: Many Entries listed as 0kb of 0kb downloaded → [BRANCH] Many Entries listed as 0kb of 0kb downloaded
Target Milestone: mozilla1.0 → mozilla1.0.2
Actually reopening this time
Resolution: FIXED → ---
QA Contact: sairuh → petersen

Comment 25

15 years ago
Confirming this issue is still occuring on the branch build (2002-10-21-05 1.0)
under OS X 10.2.1. DL entry remains as 0kb of 0kb until file transfer is completed.

Comment 26

15 years ago
Is bug 149237 a dup of this one?

Comment 27

15 years ago
Please take a look at bug 140465

Comment 28

15 years ago
Over to Jan.
Assignee: law → varga


15 years ago
Target Milestone: mozilla1.0.2 → mozilla1.4beta
adt: This is fixed on the trunk.  
Keywords: nsbeta1+ → nsbeta1-
Whiteboard: [adt3 rtm] custrtm- → custrtm-
Product: Browser → Seamonkey

Comment 30

9 years ago
This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state.

If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way.
If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar).
If no action happens within the next few months, we move this bug report to an EXPIRED state.

Query tag for this change: mass-UNCONFIRM-20090614

Comment 31

8 years ago
(In reply to comment #29)
> adt: This is fixed on the trunk.  

Let's mark it so.
Last Resolved: 16 years ago8 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.