Error message is incorrect when proxy configuration is wrong. (1) Open Preferences dialog and select Proxies tab. (2) Select "Manual proxy configuration" and enter an invalid url (ex. "invalid.url"). (3) Close Preferences dialog and try to access somewhere (ex. "cnn.com"). Error dialog says "cnn.com could not be found". But it should tell "invalid.url" is wrong. My build is 2000101308/Win32.

proxy stuff to networking.

Confirmed 110104 Win98. The error message should say something like "Unable to connect to proxy invalid.url:8080" so the user isn't left wondering "Why is Moz/NS trying to connect to invalid.url when I told it to connect to cnn.com?". There are some older bugs reporting different, also incorrect results when the proxy is down or the proxy settings are incorrect. I was only able to reproduce this bug. (The other bugs are reported against linux.. that might be why.) bug 36265 no error message bug 50176 "can't find keywords.netscape.com"

->neeti

I ran into this today when I forgot that I still had ftp proxy settings enabled from some debugging. Nominating for 0.9.1

qa to me. I need to do a full review of the error states and document how we behave anyhow. The basic plan is to update, then follow the "Generic Proxy test suite"

UPDATE: Win32, 2001-06-07-13-091, commercial. I've expanded the testing around this area and found that there are two areas we should consider changes: 1- Status bar. I've outlined these changes in bug 11708, which I re-opened. 2- Error messages: The three error states I currently test for all have incorrect "Alert" text. Proxy hostname not in DNS says: "<URL.fqdn> could not be found. Please check the name and try again>". Proxy not running on socket (connection refused) "The connection was refused when attempting to contact <URL.fqdn>." Proxy does not exist (unreachable/offline) says "The operation timed out when attempting to contact <URL.fqdn>

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

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

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

Bugs targeted at mozilla1.0 without the mozilla1.0 keyword moved to mozilla1.0.1 (you can query for this string to delete spam or retrieve the list of bugs I've moved)

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

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

Build 2002010419 OS OS/2 I have configured a local proxy at 127.0.0.1. If this proxy is not running, mozilla doen't give an error response at all. If I type a URL and press enter, nothing happens.

I still see this problem with BuildID 2002011807 on RedHat Linux 7.2

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

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

+nsbeta1 - proxy connections are "transparent", so these error messages will really confuse users and make troubleshooting difficult.

Couple items: If this is an error, doesn't docshell get to implement this? Also, can we make this a build or pref option? Some ISV's are also the ISP, and have integrated proxy service. They might want to make the errors less transparent. Compuserve is a good example. If possible, do we have a contact w/ them, to ask about their needs? I had to make hardcoded changes for something that someone doesn't want.

We need to provide teh correct info to docshell. This will only show if we set teh proxy up in prefs - we can't know about transparent proxies, so those are not an issue.

As I understand it, Compuserve isn't using transparent proxies, they just configure every client to use their proxy.

cc'ing darin

*** This bug has been marked as a duplicate of 11708 ***

This bug is about error messages... is the fix going to be the same?

yeah, very much related.

This bug was duped to a bug that was WONTFFIX. Is this something that now needs to be fixed separately?

darin

yes, this should be fixed.

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

-> moz 1.3

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

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

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

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

here's a patch which partially fixes the problem. instead of saying that such and such host could not be found or could not be contacted, we indicate that "the proxy you have configured" cannot be found or cannot be contacted. while it would be nice to actually give the proxy hostname in this error dialog, i don't think it is absolutely required to solve this bug. just knowing that the problem is with the proxy server and not the origin server is usually way more than "half the battle."

Comment on attachment 107479 [details] [diff] [review] v1 patch You seem to have change a whole lot of success codes to failure, and teh other way arround. Why?

bbaetz: no, in fact i only changed some "error" codes to success codes. we have a bunch of nsresults that are used as indices into the necko string bundle (via nsIErrorService). these status codes are not error codes, but nsresults used to represent the various network-level states of the status bar. several people have commented that it doesn't make sense to declare these as errors, and i agree. so, i figured while i'm cleaning up necko's error codes that i might as well clean up the status-bar codes as well.

Comment on attachment 107479 [details] [diff] [review] v1 patch Hmmmm r=bbaetz, then. I'm not convinced that it won't break something subtle, even though it shouldn't.

ok, i kept the status codes as "failures" because too much JS code has the numeric values hardcoded :P fixed-on-trunk

Mozilla 1.3a, Win98. DNS - hostname not found: "The proxy server you have configured could not be found. Please check your proxy settings and try again." Darin: the other two conditions do not seem to give accurate errors, do you want me to VERIFY and open new bugs? Connection refused (system available, but not servicing the port): "The connection timed out while attempting to contact <HOSTNAME>." Connection timeout (no system at IP address) "The connection timed out while attempting to contact <HOSTNAME>.""

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

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

VERIFIED: Mozilla 1.3a - Mac OS X and Linux

I looked at the patch and darin had fixed connection refused. So I re-tested Mozilla 1.3a, and connection refused errors work as expected, not the way I described in #39. (I possibly had used SOCKS, which has these error problems (bug 129502) See bug 197697 about the client-proxy timeout error.