Closed Bug 100816 Opened 23 years ago Closed 23 years ago

FTP: need errror for DNS error - nonexistent hostname.

Categories

(Core :: Networking: FTP, defect)

Product:
Core
Component:
Networking: FTP
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
VERIFIED FIXED

People

(Reporter: tever, Assigned: bbaetz)

References

(
URL
)

Details

(Keywords: relnote)

Overview Description: Seeing this when hitting a number of sites that are not resolving such as ftp.freesoftware.com, ftp.pcgamer.com . We should get an error message like in 4.7. Steps to Reproduce: 1.) type in the supplied url Actual Results: busy bar spins, Finished FTP transaction message at bottom, but nothing happens. Expected Results: Should get a 'unable to locate server' message of some sort and I don't think we should get the 'finished' message Build Date & Platform Bug Found: WinNT 2001091903 Additional Builds and Platforms Tested On: also happens on linux and mac
Keywords: 4xp
ftp->me dougt, this is caused by the following lines in nsFtpState::StopProcessing: nsresult broadcastErrorCode = NS_OK; if ( NS_FAILED(mControlStatus) || NS_FAILED(mInternalError)) { // Lets mask the FTP error code so that a client does not have to parse it broadcastErrorCode = NS_BINDING_ABORTED; } why was this done? Changing it to: nsresult broadcastErrorCode = mControlStatus; if ( NS_SUCCEEDED(broadcastErrorCode)) broadcastErrorCode = mInternalError; makes this work, at least from testProtocols (I get layout crashes on a current build; I'll repull and then test)
Assignee: dougt → bbaetz
changed summary for clarity
Hardware: PC → All
Summary: mozilla should display error message if it cannot resolve host → FTP: need errror for DNS error - nonexistent hostname.
This does fix it, but I'd like feedback on why this was done.
this change makes good sense to me (r/sr=darin)
r=me. looks good.
I checked this in last night, but forgot to mark it fixed. Oops.
Status: NEW → RESOLVED
Closed: 23 years ago
Resolution: --- → FIXED
*** Bug 103155 has been marked as a duplicate of this bug. ***
an error message now displays, but the main window loads a page showing yhis in clear text: <html><body></body></html>
Thats bug 19073 - my patch in that bug fixes that problem (I have that tested, which is why I didn't notice)
Keywords: oeone
*** Bug 104354 has been marked as a duplicate of this bug. ***
Marking dep - that patch fixes this.
Depends on: 19073
+relnote: RELNOTE for Nescape 6.2: "FTP does not display errors when connecting to DNS hostnames that do not exist."
Keywords: relnote
removing item for this fixed bug from mozilla 0.9.6 release notes.
Testing on the following: Windows: 11_07_09_trunk MacOS9: 11_08_08_trunk MacOS10: 11_08_04_trunk Linux: 11_08_08_trunk Verified fixed on trunk. Message now comes up when server cannot be located. However, on Mac and Linux, a blank page comes up with the following: <html><body></body></html> which is described in bug #106558 and is unrelated to the issue of this bug.
Marking verified on trunk and nominating for EDT. If user goes to an FTP site that cannot be found, there should be a message generated as in 4.7.
Status: RESOLVED → VERIFIED
Keywords: edt0.9.4
can someone verify that... - cancelling FTP downloads still works? - stopping long dir listings still works? - dialog is thrown when the host doesnt' exist? - dialog is thrown when an FTP server isn't running on an existing FTP host? also, watch for throbber funkiness.
Which branch/
I verified all of the items I suggested above on a trunk build from today. Bradley, can you drive this into the 0.9.4 branch?
Keywords: edt0.9.4 → edt0.9.4+
darin, dougt - can you check that this works, and then commit it to the branch? Note that you will probably get the blank page unless one of the uriloader patches (either mine, or rpott's more extensive one) is applied as well, I think. rpotts?
yeah... i believe that if we want to eliminate the empty page on the 0.9.4 branch then we'll need to land my URILoader patch as well :-) that's the patch attached to bug #106558
it looks to me that edt is confused :-) we either need to take both this bug and http://bugzilla.mozilla.org/show_bug.cgi?id=106558 or none of them (that's the conclusion based on engineering recommendations above). Currently http://bugzilla.mozilla.org/show_bug.cgi?id=106558 is set to edt0.9.4-. EDT, unconfuse itself! :-) What are the risks from taking both patches?
since the patch for bug #106558 had been baking on the trunk for a while -- with no noticable regressions it should be safe to pull it into the 0.9.4 branch. i believe that any regressions would be fairly obvious... so they should have been discoverred by now :-) -- rick
EDT - Okay, you win we are fools. Will plus both bugs. Chofmann loves you.
I'm on holiday - can someone please check this into the branch (if it wasn't done already?)
[My Notes - so i don't forget what i was working on!] The following notes are related to getting this bug fixed on the 0.9.4 branch: 1. Applying the change mentioned by Bradley at http://bugzilla.mozilla.org/show_bug.cgi?id=100816#c1 to 0.9.4 does indeed produce the "unable to locate" server message. 2. However, we get still the <html><body></body></html> on the page after the above msg. We need to apply patch in http://bugzilla.mozilla.org/show_bug.cgi?id=106558 as well to take care of this. 3. Where does the patch in http://bugzilla.mozilla.org/show_bug.cgi?id=19073 fit into this whoel thing. Can someone comment on it?
1. it's looking like this bug should be marked a dupe of 100816, and that patch should be applied to 0.9.4. 2. your #3 question... I think we can ignore that patch (per bbaetz's comment in #19 above).
Checked in the following changes to the 0.9.4 branch: 1. Change mentioned in http://bugzilla.mozilla.org/show_bug.cgi?id=100816#c1 2. The "even better patch" in http://bugzilla.mozilla.org/show_bug.cgi?id=106558
Keywords: fixed0.9.4
+verified 0.9.4 - used the first daily build that had this fix (jmkobayashi's system)
Keywords: fixed0.9.4 → verified0.9.4
You need to log in before you can comment on or make changes to this bug.