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.

Right. We don't get begin getting notifications until the location is actually chosen. I don't think this is Download Manager's fault.

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.

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

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.

Blake, did progress dialogs ever say 0 of 0?

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.

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

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

removing plus for retriage

nsbeta1+/adt3 per Nav triage team.

fixed

fixed

Mass removing adt1.0.0, and adding adt1.0.1 because, we are now on 1.0.1.

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.

really marking vrfy'd fixed [for the TRUNK].

adding adt1.0.1+. Please get drivers approval before checking into the branch.

please checkin to the 1.0.1 branch. once there, remove the "mozilla1.0.1+" keyword and add the "fixed1.0.1" keyword.

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

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?

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

adt1.0.1- per the ADT. let's get it in the next release.

re-opening and retargeting for 1.0.2. Please ask for approval for 1.0.2 when it opens. Removing mozilla1.0.1+

Actually reopening this time

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.

Is bug 149237 a dup of this one?

Please take a look at bug 140465

Over to Jan.

adt: This is fixed on the trunk.

MASS-CHANGE: 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

(In reply to comment #29) > adt: This is fixed on the trunk. Let's mark it so.