Split-off of bug 11708 Currently, I think, when you have configured a proxy and Mozilla hits a webserver, it displays "Connecting to <webserver>" in the beginning, while in fact it is connecting to the proxy first and only then lets the proxy connect to the webserver. This is usually not problem, but it would be, if - the server is not reachable - the server is far away from the client (e.g. an anonymizer implemented HTTP proxy, this stuff exists to my knowledge) So, add a stage during which the Mozilla puts out a status message in the status bar like "Connecting to proxy <proxy>".

relevant thread from original bug... ------- Additional Comment #46 From Benjamin Chuang 2002-09-05 22:08 ------- VERIFIED: Netscape 7.0, allplats I think the format I suggested isn't too complicated, and it would easily tell a user what is going on. If people only used manual configs, I would agree w/ Darin, but when you use complicated PAC files, this would be really nice. That being said, I'm not going to file a new bug, if someone decides they want this and it's meant to be, I'm sure someone else will file. ------- Additional Comment #47 From Darin Fisher 2002-09-05 22:37 ------- benc: good point about PAC, but on the flip side of the coin, PAC is probably used a lot by folks who have absolutely no idea what a proxy server is. i'm more interested in the bug about "host not found" or "connection refused" specifying the origin server when in fact it should be specifying the proxy server (and i think that bug is filed elsewhere). ------- Additional Comment #48 From Ben Bucksch 2002-09-06 00:00 ------- filed bug 167028 about adding a status message for connecting to the proxy (i.e. part of benc's suggestion). ------- Additional Comment #49 From Mike Shaver 2002-09-06 05:09 ------- PAC files are indeed used by people who have no idea what a proxy is, in which case the PAC file is provided by a corporate or ISP administrator (or put-upon housemate, I suppose). In that case, being able to ask the user "what does it say in the status bar when it's just sitting there?" would be a minor miracle, and would contribute materially to the quality of both the user's and the administrator's lives. (In a former life, I spent literally days debugging dynamically generated 4.x PAC files at a VAR installation, with a combination of **** tools like tcpdump and netcat. I'm generally a bit fan of writing for "diagnosability" -- no silent failures, etc. -- but this case is especially close to my heart.) (BenC agrees here, he used to be the lead support engineer for Netscape Proxy...)

i think this bug would be a non-issue if we just reported errors sufficiently. the problem with most browsers is that they don't; hence this bug report (which is really more of a proposed solution rather than a real problem report). am i correct in stating that the problem is that users have a hard time figuring out connectivity problems related to proxies due to the fact that we lie to the user and say that we are connecting to foo.com when we're really connecting to some proxy server?

> this bug report (which is really more of a proposed solution rather than a real > problem report Strictly, the current status messages are wrong. They say that Mozilla connects to the webserver, when it really connects to the proxy. > am i correct in stating that the problem is that users have a hard time > out connectivity problems Assuming that status messages are important at all, then the status message of connecting to the proxy is important, especially in cases where the proxy is far away from the client. There might be no error, but a significant delay of e.g. 1 or more seconds.

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