Closed Bug 148881 Opened 22 years ago Closed 22 years ago

cancelling ftp download before save file dialog is presented gives "file could not be saved" error message

Categories

(Core Graveyard :: Networking: FTP, defect)

x86
All
defect
Not set
minor

Tracking

(Not tracked)

RESOLVED FIXED

People

(Reporter: bugzilla4dave, Assigned: dougt)

References

()

Details

From Bugzilla Helper:
User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.0.0+) Gecko/20020601
BuildID:    2002060108

Today for some reason, ftp.mozilla.org seems to be misbehaving today (can't
connect or can't retrieve directoy listing).  I got impatient and cancelled the
download of the installer for the win32 build of Mozilla from Mozilla.org's home
page (pressed stop/hit escape), but instead of "just sort of cancelling,"
Mozilla gave me a modal error dialog (see below).

Reproducible: Every time
Steps to Reproduce:
1.  Click on either of the following links (or paste one into the location bar
and press enter):
ftp://ftp.mozilla.org/pub/mozilla/nightly/latest/mozilla-win32-installer-sea.exe
ftp://ftp.mozilla.org/pub/mozilla/nightly/latest/mozilla-i686-pc-linux-gnu-sea.tar.gz
2.  Press Mozilla's stop button or press the escape key
(I guess all this will only work if the server is misbehaving, I don't know.)

Actual Results:  Mozilla gives modal error dialog with no window title and the
following error message:
"C:\WINDOWS\TEMP\<some_random_file_name>.exe could not be saved, because the
source file could not be read.

Try again later, or contact the server administrator."

Expected Results:  There's no error on the part of the user, and nothing to
report that the user has any control over, so Mozilla should not give an error
message; and Mozilla shouldn't try to copy a file whose download was cancelled
(it says that's what it's doing, so I can only assume it is).

I am guessing above that the file "has not really begun downloading."  This is
because the server does not even seem reachable (checked with other ftp
clients), and the temp files have 0 size.  The temp files only show up in the
windows\temp directory _after_ I cancel the download, which is also strange.
See also (about how Mozilla downloads files):  Bug 55307; Bug 69938, Bug 103877,
Bug 55690.
I have not been able to reproduce this behavior with any example other than the
one I give above:  I only experienced this behavior when I cancel the download
of the Windows and Linux i386 builds, although it doesn't matter whether I click
on the link, try opening it in a new tab or window, or enter it in the location bar.
Maybe someone else can tell what is going on here better than I can, and why it
is only a problem with certain links, even on the same server.  I am also making
the assumption that it is the server and not my connection or system that is
misbehaving.
Summary: cancelled download of my platform's nightly build from ftp.mozilla.org not handled graceful → cancelled download of some nightly builds from ftp.mozilla.org not handled gracefully
I have found out the difference between my example links and the other links
@mozilla.org:  the links to the Windows and Linux i386 builds are ftp: links;
the others are http: links.
Seems like "misbehaving" ftp servers only, so changing summary; example URL; and
component -> Networking:FTP for now (owner, pls. send elsewhere if I'm wrong).
What I describe as "misbehaving" ftp server is one that lets you log on but
won't give you a directory listing and won't allow file retrieval.  (Don't know
why ftp.mozilla.org is doing this to me, but it's sort of irrelevant).
Component: File Handling → Networking: FTP
Summary: cancelled download of some nightly builds from ftp.mozilla.org not handled gracefully → cancelled download from misbehaving ftp server not handled gracefully
Seeing on Linux:  OS->All
Can work around by using "Save Link Target As..." instead of opening with click
or in new tab/window:  Severity->minor
Severity: normal → minor
OS: Windows 98 → All
Component: Networking: FTP → File Handling
Doesn't seem to matter whether server is "misbehaving" or not.  (changing
summary _again_, sigh...)
Summary: cancelled download from misbehaving ftp server not handled gracefully → "file could not be saved" dialog on cancelled ftp download
Adjusting summary one last time.  I don't usually do this, but it turns out I 
misdiagnosed this problem from the beginning, and never did get the summary
quite right until just now.
Boris, I am CC'ing you because I suspect that this bug may be related to "some
residual problem[s]" in "reporting of errors while saving files" Bill law
mentions in Bug 27609 Comment 96.  You advised that you were interested in these
bugs, so maybe you can:
a) decide if this bug falls under these "residual" problems Bill mentions;
b) classify as a dupe you know of/can find (I was not able to find anything like
this report from among all new/assigned/reopened file handling bugs created
since 2002-02-22 -- the date on which 27609 was marked resolved fixed); or
c) mark it new/assigned/whatever is appropriate.
To clarify my thus-far muddled report:  when cancelling an FTP download before
the save file dialog pops up, I get an error message:
"C:\WINDOWS\TEMP\<some_random_file_name>.exe could not be saved, because the
source file could not be read.

Try again later, or contact the server administrator."

Thanks, Boris.
Summary: "file could not be saved" dialog on cancelled ftp download → cancelling ftp download before save file dialog is presented gives "file could not be saved" error message
Confirming.  Steps to reproduce:

1)  Click on
ftp://ftp.mozilla.org/pub/mozilla/nightly/latest/mozilla-win32-installer-sea.exe
2)  Quickly hit "Escape" before the helper app dialog comes up

Doug, it looks like an OnStopRequest with an error status is fired in this
case... is that the right thing to do?
Assignee: law → dougt
Status: UNCONFIRMED → NEW
Ever confirmed: true
yes, i think so.  The request was cancelled.  the error that onStopRequest is
firing should be NS_BINDING_ABORTED.
Hmm.. so why is this not happening with HTTP?  The code in question lives at:

http://lxr.mozilla.org/seamonkey/source/uriloader/exthandler/nsExternalHelperAppService.cpp#1440

in nsExternalAppHandler::OnStopRequest and it just triggers off of NS_FAILED...
I'd have no problem changing this to not trigger on NS_BINDING_ABORTED or making
the OnStartRequest set mCancelled if the status there is already
NS_BINDING_ABORTED.. the problem is, how do I differentiate a NS_BINDING_ABORTED
due to a timeout contacting the server and a NS_BINDING_ABORTED due to the stop
button being pressed?
ftp is broken.  :-/

I am going to roll this fix in with other FTP changes.
FTP should not be generating the NS_BINDING_ABORTED error code.  it only leads
to confusion, and there is no reason why FTP can't use some other, more
meaningful error code.
Component: File Handling → Networking: FTP
QA Contact: sairuh → benc
Fixed on trunk
Status: NEW → RESOLVED
Closed: 22 years ago
Resolution: --- → FIXED
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.