Closed Bug 167820 Opened 22 years ago Closed 22 years ago

Two failure dialog after failed ftp request

Categories

(Core Graveyard :: Networking: FTP, defect)

Product:
Core Graveyard
Component:
Networking: FTP
Version:
1.0 Branch
Platform:
x86
Windows 2000
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

Status:
VERIFIED WONTFIX

People

(Reporter: dougt, Assigned: dougt)

References

Details

A spin off bug from 162326.  

There is a second dialog which is displayed:

http://bugzilla.mozilla.org/attachment.cgi?id=98491&action=view

Boris's summary in comment #14 sums everything up nicely.

OK.  Just a quick summary of an email conversation I had with Doug:

1)  The ftp channel will pop up an alert when an error occurs saying that the
    error occured.  It will then call OnStopRequest with an error code.
2)  The save-as code will pop up an error alert (like what you see in attachment
    98491 [details]) if its OnStopRequest is called with an error code.  It has to do this
    to handle protocols, like HTTP, for which the channel does no error
    notification of its own.

So you are seeing two alerts for the same error.
The only proposed solution so far is to pop up an alert if and only if the
nsIRequest status is a success but the aStatus passed to OnStopRequest is a
failure code...  Is this a reliable way of dealing?  
what does that really mean?

you have a request who's status is successful, but the onStopRequest status is
failure?  I would really like these two be the same value in all cases.  

How about a special success status code?
Hmm, nevermind.  I guess those _are_ the same value all the time, pretty much.

A special success code indicating what exactly?  Would this then be documented
on the nsIRequest or nsIStreamListener interface?  (can we change those
interfaces like that?)
More email discussion that should really end up here:

Q:  Why do we have that code in FTP networking?
A:  Because the docshell doesn't handle that error notification
Q:  Maybe we should fix the docshell and move this stuff out of necko?
A:  Probably a good idea.
We really need a rich way to tell clients of necko what exactly happened with a
given request.  Then a deciding can be made if this information should be
intergrate into the browser's UI.  For example, maybe mozilla doesn't want to
tell the user that the permissions are messed up on a remote file, but an
advanced FTP client would.  

FTP can stop using the nsIPrompt to indicate what kind of error occured when
there is a new kind interface which allows me to broadcast these kind of
messages from the server.  It could be FTP specific, but I am sure that is can
be shared with other protocols.  

Maybe this object  can be made QI-able off the request.  Or maybe it it should
be a interface which is QI'ed from the Notification Callbacks.  I kinda like the
idea of using the notification callbacks.  

as an interface QI'able from nsIRequest, you get the advantage that it is really
easy for embedders to pick and choose not only how they display the error, but
when.  by making it a callback from FTP code, you force the UI to either display
the error message right then, or perhaps buffer the information to be displayed
later, which is not so nice.  i'm thinking of error pages here.  docshell would
probably rather have a rich interface to query when an error occurs instead of a
callback that it must handle.

this interface would also allow us to clean up a lot of the HTTP error handling.
 e.g., we have that bug about "host not found" for proxy servers, which is
difficult to solve in the current world.
Strawman:

interface nsIxxx : nsISupports {
  readonly attribute boolean  successful;
  readonly attribute long     serverStatus;
  readonly attribute AString  serverMessage;
}
And then we can move that "successful" off nsIHttpChannel?  sounds good to me!

Is server status typically a single number for all our protocols?  Is there ever
a "sub-status" or something?
see bug 56629 for the somewhat related problem of proxy host DNS failures.
*** Bug 151935 has been marked as a duplicate of this bug. ***
Just an update on the summary of the bug.

Using 2002-09-09-08  1.0, when ftp server is stopped,
I don't have the first error message from FTP channel.

It goes to save as dialog directly and when I attempt to save,
I get a message looking like the attachment,
http://bugzilla.mozilla.org/attachment.cgi?id=98491&action=view

Thanks.
handsoodev, right.  two dialogs will only happen if the client FTP code executes.  

It is easy to stop FTP from displaying alert notifications.  Just comment out
the code in StopProcessing that calls  Alert().  However, we go from rich error
reporting to docshell error reporting.  

Can someone clairfy what the real problem is here?

From the steps and the error dialog provided, it sounds like this is:

Get a FTP dir listing, then kill the server before you try to get the file.

I'm asking because I'm trying to verify the dupe (Bug 151935), and it doesn't
sound like the same thing (and is also fixed in mozilla 1.2a anyhow).
>Can someone clairfy what the real problem is here?

both the docshell and the ftp protocol are posting error messages, hence two
failure dialog after failed ftp request.
*** Bug 151935 has been marked as a duplicate of this bug. ***
Which two error messages? I don't see anything that resembles the attachment
described by Hansoo, and the problem described in bug 151935 is not happening
anymore in Mozilla 1.2a.
ben, there are many cases that cause this problem.  For example, a site that has
reached the maximun number of users will prompt twice: once via the FTP
protocol, once via the docshell.
Doug,

I am not sure if we are trying to solve the same issue at this point.

Originally, when I first talked to you about the bug,
I was concerned about the following behavior.

1) Have FTP server running... ( I an using IIS )
2) Go to the root of ftp site, which has one file with NO ACCESS.
3) Try to retreive the file, and make sure you get 550 error.

==> SECOND TEST BEGINS !!!
4) Now stop the FTP server.
5) Try again on file ON THE DIR LISTING OF FTP DIRECTORY.

BOTH Embedding client and Mozilla ( and MFC embedding ) DO
NOT display 550 error on the second test...
It goes to Save as box directly...

Embedding client ==> Let me save to ZERO byte file.
Mozilla and MFC Embedding ==> Error AFTER Save AS box.

I think my point here is what we should have Save As box popped up at all in 
this case.
I think we should just get "FTP server not responding" error or the like
for this case and NO SAVE AS box.

Are we on the same page ?

Thank you in advance.
hansoo, yeah i think that you are right; this may be a seperate problem.  what
happens when you clear the cache?  
Doug,

No. it does not matter if I clear the cache or not...

The problem still shows.

FYI, the trunk does not have the right behavior,
that is, 5) Try again on file ON THE DIR LISTING OF FTP DIRECTORY.
 display " connectin refused from server" error msg...

Thanks
Oops,

I think my last comment should read as
"FYI, the trunk DOES HAVE the right behavior,"...
NOT "FYI, the trunk does not have the right behavior,"

Thanks.
Component: Networking → Networking: FTP
this is a 1.0 branch problem.  marking wontfix.  If this bug fix is important to
you, please reopen and reassign it to someone that has the time for 1.0 Branch bugs.
Status: NEW → RESOLVED
Closed: 22 years ago
Resolution: --- → WONTFIX
VERIFIED:
please repoen if anyone sees this outside a 1.0 branch build.
Status: RESOLVED → VERIFIED
Version: Trunk → 1.0 Branch
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.