Closed Bug 137676 Opened 23 years ago Closed 15 years ago

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

Categories

(SeaMonkey :: Download & File Handling, defect)

Product:
SeaMonkey
Component:
Download & File Handling
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

Status:
RESOLVED FIXED
Milestone:
mozilla1.4beta

People

(Reporter: mscott, Assigned: janv)

References

Details

(Whiteboard: custrtm-)

Attachments

(1 file)

Patch, see notes below for important additional info!
2.07 KB, patch
jud
: approval+
Details | Diff | Splinter Review
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.
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
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
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
Keywords: nsbeta1+ → nsbeta1
nsbeta1+/adt3 per Nav triage team.
Keywords: nsbeta1 → nsbeta1+
Whiteboard: [adt2] → [adt3]
Depends on: 129614
fixed
fixed
Status: NEW → RESOLVED
Closed: 23 years ago
Keywords: adt1.0.0
Resolution: --- → FIXED
Whiteboard: [adt3] → [adt3 rtm]
Whiteboard: [adt3 rtm] → [adt3 rtm] custrtm-
Keywords: adt1.0.1
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].
Status: RESOLVED → VERIFIED
Whiteboard: [adt3 rtm] custrtm- [verified on trunk] → [adt3 rtm] custrtm-
adding adt1.0.1+. Please get drivers approval before checking into the branch.
Keywords: adt1.0.1 → adt1.0.1+, mozilla1.0.1
Attachment #82864 - Flags: approval+
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+
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.
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
Status: VERIFIED → REOPENED
Resolution: FIXED → ---
QA Contact: sairuh → petersen
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.
Assignee: law → varga
Status: REOPENED → NEW
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
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
Status: NEW → UNCONFIRMED
(In reply to comment #29) > adt: This is fixed on the trunk. Let's mark it so.
Status: UNCONFIRMED → RESOLVED
Closed: 23 years ago → 15 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: