At one point, unfortunately, my ADSL was down. Similarly, the problem can be reproduced if the LAN or modem cable is inadvertently unplugged. When trying to access for example cnn, I got a pop-up saying: <<The connection was refused when attempting to connect to www.cnn.com>> which is obviously not right since they would never refuse. I assume it is technically possible to be more precise. Therefore, I suggest the error message to be: <<www.cnn.com is currently unreachable. You might want to use traceroute (tracert under windows) to determine where the problem lies.>> Build 2002053012

actually, the problem is that we are mapping most socket errors to connection refused even though we could map them to something else. such as "no route to host." i've been meaning to clean this up. -> 1.2alpha (perhaps)

I'd like to add that this is a very confusing bug for dialup (modem) users which always triggers if the connection has been hung up in the meantime and the modem is still dialing while Mozilla times out. In fact, with the modem already dialing, "Connection refused" caused both my Dad and my sister to check the cable to the modem (the "connection").. :-} Maybe Mozilla could use some switch "on dialup connection yes/no" which would adjust (lengthen) the connect() timeout (if supported by host os) and would make it handle ICMP network/host unreachables that were sent by the user's router a little more sensible (eg simple retry a connect() if the last data transfer was more than $ROUTERIDLETIMEOUT seconds away and if $TIMETODIALUP seconds haven't passed yet.) That's for semi-permanent connections that dial automatically, _not_ for manually dialed connections, so "Work on/offline" won't work. Just my EUR 0.02 :-)

The new "error page" (instead of dialog box) model has been implemented, but not turned on by default. When (if) the error pages replace dialog boxes, this bug may be affected. bug 156997 - [RFE] Should use error page and not dialog for inaccessible pages (placeholder) Once error pages replace dialog boxes, the following bug would apply: bug 156997 - Fix up error pages with plain English descriptions and a nice appearance After the back-end (socket mapping) is complete, the front-end can be fixed up. (Or prepare the front-end, and wait for the back-end to be complete).. etc...

downgrading to enhancement... might not get to this by moz 1.2

-> moz 1.3

*** Bug 180472 has been marked as a duplicate of this bug. ***

Connection refused when actually connection broken or destination unreachable is a lie. As noted in comment 2, it causes people to waste time trying to fix something unfixable. That makes enhancement an inappropriate severity.

actually changing

Zurich this afternoon had a major DSL outage and I had just downloaded 2003021208: Here comes the newest report: For URLs whose numeric IP address was cached, I got the <<The document contains no data>> alert - this is obviously wrong because there was no way it would these hosts at all. More appropriately, my SSH said: <<Connection timed out>>. Another but related to the same error message I support is http://bugzilla.mozilla.org/show_bug.cgi?id=159324.

ralf: the error message "the document contains no data" is only popping up because of bug 189965, which will be fixed by 1.3 final. the business about distinguishing a connection refused error from a route error is still unresolved. that's what this bug is about ;-)

adt: nsbeta1-

*** Bug 204182 has been marked as a duplicate of this bug. ***

Is there something happening to the bug? I think the behavior is so confusing that there are many poeple who see this but do not realize there is a mozilla problem.

patches welcome :)

-> default owner

I think mozilla applies the ( extensively platform-independent ) socket interface of the OS. Whether the server temporarily is down, not listening at the specified port or actually refuses a connection to the client address, "ECONNREFUSED" is thrown as error by "SockConnect" ( at least for Os/2 ). One solution could be to specify another message like "no response from server" to the mapped mozilla error "PR_CONNECT_REFUSED_ERROR". Relevant files : http://lxr.mozilla.org/seamonkey/source/nsprpub/pr/src/misc/prerr.c#64 ( it's automatically generated, don't know from which sources ? ). And, for Os/2, http://lxr.mozilla.org/seamonkey/source/nsprpub/pr/src/md/os2/os2_errors.c#790 . Problem is, some other modules like ldap also uses "PR_CONNECT_REFUSED_ERROR". And there the meaning really could be "connection refused". So a better solution might be to introduce an new error - "PR_CONNECT_NO_RESPONSE_ERROR" ( in "prerr.c" ) for instance - and map the socket error "ECONNREFUSED" to this new "PR_" error. To supply concrete patches I need to know whether the socket error is the reason also for other platforms ( x, win, and mac at least ) and what the source of "prerr.c" is. And to avoid regressions some advice of someone knowing the "nsprbub" module would be nice ...

(In reply to comment #16) > So a better solution might be to introduce an new error - > "PR_CONNECT_NO_RESPONSE_ERROR" ( in "prerr.c" ) for instance - and map the > socket error "ECONNREFUSED" to this new "PR_" error. "no response while trying to connect to server" could be an appropriate message.

"security/nss" and "directory/c-sdk/ldap" ( which also use "PR_CONNECT_REFUSED_ERROR" ) seems to work indepedently. So I can leave this alone and just change the text in the locales ( here for the seamonkey suite, tested on trunk 2007-09-18 5:00 , Build identifier: Mozilla/5.0 (OS/2; U; Warp 4.5; en-US; rv:1.9a8pre) Gecko/2007092019 SeaMonkey/2.0a1pre ) ...

Stefan, if you still want this patch in the tree, you should find another reviewer. I think Darin doesn't do that any more. You can look on http://www.mozilla.org/owners.html for "suite". And if you ask me, you should at the same time change the respective files under mail/, too, see http://mxr.mozilla.org/seamonkey/search?string=connection.*refused&regexp=on&find=proper

Comment on attachment 281686 [details] [diff] [review] changes the text from "the connection was refused" to "no response". Sorry, I'm the wrong reviewer for this change.

OK, will change patch and reviewer as proposed in #19 / #20 until the weekend ...

why not keep the original text as returned by the operating system? this mania of Firefox to replace all error messages with a paraphrase is really, really annoying. Why is this being done at all, exactly? Most object oriented languages, including C++, support putting arbitrarily long strings into exceptions, so there's really no need to map all error conditions to integers and then back to strings. Moreover, as exceptions are fully-fledged objects, they can actually contain _both_ a string and an integer code, which should ease the transition. An usable error messages are one place where bloat is justifiable. Do we really have to keep strace and tcpdump around to make sense of Firefox' error messages?

The connect() call on Linux has nice diagnostics like ENETUNREACH and ETIMEDOUT. Windows provides WSAENETUNREACH, WSAETIMEDOUT. Even if they are not mandated by a standard or are not present on OS/2 the presence of these values can be detected. Does Mozilla even still run on OS/2? So the error here is that Mozilla uses nice portable socket interface with nice portable diagnostics and then trashes the diagnostics obtained and just says that connection was refused whatever the error was. The patch only makes the error message as vague as the Mozilla error handling is. It does not fix the actual problem.

This is broken beyond belief. If Windows gives sucky error messages, then just have Firefox on Windows relay those. But, for the love of God, keep the usable messages from the OS when Firefox happens to run on a sane platform! Use perror() or strerror() where available. Use a generic/paraphrased message where strerror() is not available, AND ONLY THERE. The worst part is that this Windows mentality is all over the place. I just logged another bug where Thunderbird transformed a "disk full" error message into "please switch off encryption"!

Actually, windows is not to blame here. It provides perfectly fine diagnostics on it connect() call according to the MSDN docs. Mozilla just 'translates' the messages into unintelligibility.

(In reply to Michal 'hramrach' Suchanek from comment #23) > Does Mozilla even still run on OS/2? OS/2 is a holdover nomenclature from the IBM origins of the http://www.ecomstation.com/ OS, plus there are still some OS/2 users around nursing their systems into the future via eCS updates. Its users are all running the ESR branch currently, as manpower is lacking to port or update tools required for building main branch.

ETIMEDOUT based on comment 21