problem: when visiting said URL, can clicking on the "301 or later" download link in the right column, a save-as dialog is thrown, then a download progress dialog. a file of zero length gets created on the file system, however, the ftp server isn't even accessible. expected results: a dialog gets thrown telling the user the server can't be reached.
Severity: normal → major
Status: NEW → ASSIGNED
Target Milestone: --- → mozilla1.2beta
Status: ASSIGNED → RESOLVED
Last Resolved: 16 years ago
Resolution: --- → DUPLICATE
not so fast.... this is clearly a new regression.
Status: RESOLVED → REOPENED
Resolution: DUPLICATE → ---
the nsOnStopRequestEvent depends on the request having the a valid status. however, we are not setting the internal state before making use of this event. This patch fixes it for me. Index: nsFtpConnectionThread.cpp =================================================================== RCS file: /cvsroot/mozilla/netwerk/protocol/ftp/src/nsFtpConnectionThread.cpp,v retrieving revision 1.250 diff -u -r1.250 nsFtpConnectionThread.cpp --- nsFtpConnectionThread.cpp 30 Sep 2002 21:50:17 -0000 1.250 +++ nsFtpConnectionThread.cpp 9 Oct 2002 04:55:34 -0000 @@ -2381,6 +2381,8 @@ if ( NS_SUCCEEDED(broadcastErrorCode)) broadcastErrorCode = mInternalError; + mInternalError = broadcastErrorCode; + if (mDPipeRequest && NS_FAILED(broadcastErrorCode)) mDPipeRequest->Cancel(broadcastErrorCode); Can I get a r/sr?
sorry for incorrect duping....
a=dbaron for trunk checkin
I landed this sometime last week. Marking Fixed.
Status: REOPENED → RESOLVED
Last Resolved: 16 years ago → 16 years ago
Resolution: --- → FIXED
Build: 2002-10-25-04-trunk A dialog appears indicating server cannot be reached. This reflects expected behavior. Marking Verified!
Status: RESOLVED → VERIFIED
QA Contact: benc → jimmylee
You need to log in before you can comment on or make changes to this bug.