STEPS: find an IP address that is not routed on your network. This is harder than it sounds, because many public networks seem to drop unroutable packets rather than return ICMP errors. (This causes a timeout vs. a routing error). for example, ping -v in Mac OS X returns "Destination Host Unreachable". Try to connect using HTTP to the unreachable address. OBSERVED: Throbber runs, then stops (roughly after the connection establishment timeout period). No error. Unlike bug 115982, no change in the status line. EXPECTED: Because the reachability is a possibly transient problem in a multi-route environment, the client should (according to Stevens in TCP/IP Illustrated, Vol. 1), not immediately display the error, unless the current TCP/IP activity fails (establishing connection, transmission timeout, etc.) If a connection failure occurs, then display the error as the cause. NOTE: you might need to play w/ your verison of ping to get it to display ICMP errors.

Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4b) Gecko/20030430 I can confirm this. I easily have that here. I just try to connect to a work station which is offline. First it says (status bar) "Connetcting to $hostname...", shortly thereafter "Done". No error message. pi

Is the mac using EHOSTUNREACH when the host is unreachable (ICMP message received form a router) ? When the host is reachable, and there's no process listening on the port (no webserver running for instance), you get a ECONNREFUSED, and I can see the "connection was refused" dialog.

This is distinct from that (test http://www.mozilla.org:81 to see connection refused.)

benc: i think this is a duplicate bug report. *** This bug has been marked as a duplicate of 152781 ***

This is not a dupe. This bug here shows *no* error message. Bug 152781 shows the wrong one. And I have another one: http://143.229.29.231:81/ASL/Meetings.htm fails: [3.14@pi ~]$ telnet 143.229.29.231 81 Trying 143.229.29.231... Connected to 143.229.29.231. Escape character is '^]'. Connection closed by foreign host. So it kicks me right away. Mozilla does not show an error if you klick on a link to that address or enter it directly. In the latter case an empty page is shown. pi

good point. i'm going to mark a dependency though to flag the relationship. as for your testcase, it doesn't cause any error for me. can you please enable these environment variables to collect a socket transport log: NSPR_LOG_MODULES=nsSocketTransport:5 NSPR_LOG_FILE=/tmp/log.txt if on windows, NSPR_LOG_FILE=c:\log.txt i'd love to see the log file so i can figure out what NSPR error you are hitting. thanks!!

Darin, the server was fixed already. I'll produce logs the next time I find something like this. pi

Looking at the two bugs together, I'm confused about the distinction now.

this shows an unable to connect error page now