Closed Bug 98394 Opened 23 years ago Closed 23 years ago

FTP download dialog ends at 98%, 99%

Categories

(Core Graveyard :: File Handling, defect)

Product:
Core Graveyard
Component:
File Handling
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

Status:
VERIFIED FIXED
Milestone:
Future

People

(Reporter: cedric, Assigned: law)

References

(
URL
)

Details

(Keywords: regression)

Attachments

(5 files)

Broken dialog
290.09 KB, image/jpeg
Details
Another try...
18.40 KB, image/jpeg
Details
Dialog with 2001092403
18.99 KB, image/jpeg
Details
Screenshot from 2001120603
6.23 KB, image/gif
Details
Screenshot showing the problem
18.97 KB, image/jpeg
Details
From Bugzilla Helper: User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.3+) Gecko/20010904 BuildID: 2001090408 After finishing a download, the dialog stops at 98% See attached dialog image Reproducible: Most of the time Steps to Reproduce: 1.go to ftp://ftp.openbsd.org/pub/OpenBSD/2.9/i386/ 2.download floppy29.fs 3.wait the end of download Actual Results: the download finishes, but the progress info stays at 98% or 99% Expected Results: the progress info should show 100%!
Attached image Broken dialog —
The attackment is broken :-)
Attached image Another try... —
Yeah, sometimes it works. I've tryed 3 times. I've got: - first try: 98% - second try: 100% - third try: 99%
I can confirm this. When downloading the file in Mozilla 2001091003 under Win2ksp2, I had it end at 98% with 1 second remaining, even though the file was done. Unfortunately, I can't "confirm" the bug under my current Bugzilla login :-P
-> xpapps for initial triage
Assignee: dougt → pchen
Component: Networking: FTP → XP Apps
QA Contact: benc → sairuh
Marking WFM 2001092208 on Win2k. Reporter: Please try a more recent build, and reopen this bug if it still occurs for you: http://ftp.mozilla.org/pub/mozilla/nightly/latest/
Status: UNCONFIRMED → RESOLVED
Closed: 23 years ago
Resolution: --- → WORKSFORME
Reopening. Downloaded latest build (2001092403) and reproduced it the first try. Dialog attachment following.
Status: RESOLVED → UNCONFIRMED
Resolution: WORKSFORME → ---
Attached image Dialog with 2001092403 —
What's more is needed to confirm this bug? Am I dreaming? It is a fresh (emptied directory) install on W2KSP2
Ok, I can't reproduce it, but marking NEW.
Status: UNCONFIRMED → NEW
Ever confirmed: true
i've seen this off and on, and on various platforms too, like Mac. for me, however, it seems erratic. :( ->law, but punt as needed.
Assignee: pchen → law
still a probtem. nominating.
Blocks: 78106
Keywords: mozilla0.9.5, regression
OS: Windows 2000 → All
Hardware: PC → All
Target Milestone: --- → mozilla0.9.6
spam: over to File Handling.
Component: XP Apps → File Handling
*** Bug 104014 has been marked as a duplicate of this bug. ***
Another testcase ("Reproducable every time with this file"), from dupe bug 104014: ftp://ftp.heise.de/pub/ct/register/khpro14b.tgz
->0.9.7 Not top priority.
Target Milestone: mozilla0.9.6 → mozilla0.9.7
*** Bug 109686 has been marked as a duplicate of this bug. ***
Mass moving bugs that won't get fixed this milestone.
Target Milestone: mozilla0.9.7 → mozilla0.9.9
*** Bug 111850 has been marked as a duplicate of this bug. ***
*** Bug 112839 has been marked as a duplicate of this bug. ***
balancing move of Helper App Mgt feature work bugs to this milestone
Keywords: nsbeta1+
Target Milestone: mozilla0.9.9 → mozilla1.0
The bug is still there, I rediscovered it while trying to download the latest Netscape 6.2.1 installer from Netscape.com. The difference from previous attachments is that the "launch file" button is not activated until we reach 100%, and I only got to 95% and 98%.
*** Bug 114654 has been marked as a duplicate of this bug. ***
*** Bug 116061 has been marked as a duplicate of this bug. ***
The bug still exists in 0.9.7. The trick is to download a small file on a slow connection. I've had a percentages of 59% (see new attachment).
This is a serious usability issue, because I can't tell from looking at the download dialog whether the download completed, or was just prematurely aborted (I'm messing in Mac networking code, and trying to test). On a fast connection, the download dialogs goes away when progress says 88% or even less. What should happen is that the dialog should stay up long enough to show 100%, persist for a short time (say 200ms), and then go away.
This is a known problem with the current progress dialog. I'm working on an update to that code that plugs this hole (as well a many others). I've linked up the bugs to reflect this.
No longer blocks: 78106
Depends on: 27609
Spam: Setting target milestone for all these to Future. Please note that most, if not all, will be fixed in the course of the work I'm doing for bug 27609. That fact is noted in the "depends on" field for each of these bugs (I think; go ahead and remedy that if you like). I just don't have time to deal with the wrath that comes with having too many bugs.
Target Milestone: mozilla1.0 → Future
This bug has the nsbeta1+ keyword. That would seem to conflict with its "Future" milestone.
Yes, but having too many bugs for a given milestone conflicts with my sanity. This one will be fixed in the course of fixing its "depends on" bug.
*** Bug 125062 has been marked as a duplicate of this bug. ***
I had this problem a few years ago, but it was reproducible on any browser. The reason was a wrong configured masquerading-setup on the linux-router/gateway. Reporter, is any firewall/linux-machine between your computer and the internet?
yes I am behind a linux-router/gateway using ipchains.
I've an OpenBSD box for NAT/Firewall (not a proxy).
I can't confirm, that this is a general problem using a firewall. Using Linux and Mozilla 0.9.8, it doesn't work with or without firewall, while on WindowsME (without firewall) it seems be quite o.k. Used download-file: ftp://ftp.heise.de/pub/ct/register/khpro14b.tgz download speed: 64 kBit/s (ISDN)
Should be fixed now
Status: NEW → RESOLVED
Closed: 23 years ago → 23 years ago
Resolution: --- → FIXED
*** Bug 126739 has been marked as a duplicate of this bug. ***
most freq dupe?
looks good --tested using 2002.02.21.0x comm bits on win2k, mac 10.1.2 and linux rh7.2.
Status: RESOLVED → VERIFIED
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: