Using build 2000030313 under Win98. Prepending the name of the proxy in the configuration with http:// will stops mozilla from accessing any site. So: www.proxy.com works http://www.proxy.com does not. Restoring plain name will make mozilla happy again. It seems to work just fine under linux.
Confirming to put this in better view.
so if I understand write you are setting your proxy to be http://foo instead of just foo? That seems wrong... but I will allow you to help me understand the problem correctly.
The behaviour is just like you described. If it's the wrong way to configure the proxy, then then instructions coming from my ISP are lame. Anyway it worked fine under NS 4.x. So maybe this is not a bug, but an idiot-proof enhancement...
Just an additional note: the mozilla profile manager will not convert the http://foo (which works in NS 4.x) in the correct one, so mozilla will be misconfigured.
Moving beta2 bugs out of M18.
Putting on [nsbeta2-] radar.
relnote: remove any leading http:// in proxy configurations in prefs.js
removing self from cc:
Still very very very broken in Mozilla build 2000080712 (on Linux). Automatic proxy doesn't work at all (with or without HTTP). The result is the same, Mozilla just doesn't try to access any sites. Manual proxy works just fine.
An additional comment: When Mozilla is started with automatic proxy settings (which don't work), and then is switched to a manual proxy setting, URLs typed into the address bar still do not work, but all links, bootmarks, and shortcut buttons do work. To fix it, you gotta shutdown mozilla. When you come back, Mozilla is happy again.
Changing the priority of this bug to P2. Getting "file:/" style URL's working with Automatic Proxy Configuration .pac files is essential to the internal deployment of Netscape 6 internally here at Sun.
Rich: The PAC is a separate problem. In order to get that working see the notes at http://www.mozilla.org/docs/netlib/pac.html They are not the best notes but should allow you to get PAC working.
Thanks Gagan. So, should we open up a separate new bug for the "file:/" PAC problem? One of my team is looking at this at the moment, and I wouldn't be surprised if he doesn't have a fix by the end of the week.
I don;t have the bug number handy but there is a PAC related bug which basically describes the problem of not being able to specify ANY URL for the PAC configuration. Currently the only way PAC works is if you copy over the contents of that PAC file to the nsProxyAutoConfig.js file. So to answer your question, yes feel free to create a new bug but be aware that it would be marked a dup of the one I just described (and can't find)
Thanks. I couldn't find it either. I've opened 53080 for the "file:/" problem, and assigned it to Akhil Arora who is just started looking at it.
*** Bug 60287 has been marked as a duplicate of this bug. ***
the suggested patch for 53080 fixes this problem. this bug should be closed as duplicate.
http bugs to "Networking::HTTP"
Changed summary to say "automatic", so we know we are talking about the same thing :)
gagan (mr. pac-man): sending this your way ;-)
I have reviewed this bug, and realized that this original problem description deals with putting a URL rather than a fqdn into the manual proxy fields. (PAC never worked, so if the reporter says it worked w/ hostnames, it was manual proxy). I have changed this summary (external-ben corrects internal-ben...), and I'll look at it soon. All the PAC issues sseem to have their own bug. My initial feeling is that we should have better documentation first, and add a friendly error message second (other errors probably are higher priority...)
Adding 4xp since this apparently works in 4.x.
IMO: this should have never worked, because you are pointing to a network socket, not a URL. However, I will not mark it invalid since it is a 4xp.
Obviously, these fields are supposed to take qdns instead of urls. However, we have no mechanism for providing feedback to the user, and a 4xp bug in preferences strikes me as having an implicit profile migration issue as well. It seemed easier just to use the educated guesswork of nsStdURLParser to pull the hostname out of the field rather than trusting the value blindly. Please review, especially to make sure I'm not leaking strings. (I haven't done much with nsXPIDLCString before.)
If we had good error checking, then we could error in prefs and when they try to hit the network w/ a bad pref. that would solve the migration problem too.
RELNOTE: Manual Proxy does not accept URLs Communicator 4 would accept a URL (http://proxy) in the manual proxy configuration. Netscape 6 only accepts hostnames. If you migrate a Communicator 4 profile, you will need to change the settings by hand.
*** Bug 49018 has been marked as a duplicate of this bug. ***
something to look at again...
-> networking, qa to me.
marking nsenterprise-; will be reevaluated for nsenterprise in future release.
gagan: chase has a patch, lets either WONTFIX or change the milestone. I vote for WONTFIX. I dislike these "4xp was stupid so we need to be also" bugs. I also went back and confirmed this in Communicator 4, and doing a full URL parse of manual configs completely confuses the auth dialog, it says things like "http://proxy:8080:0" The relnote text was really confusing to me, so I sumitted the following correction: "Communicator 4 allowed URL's in manual configuration, but Mozilla does not. If you migrate a profile configured this way, you will need to change the URL to a hostname and port number."
*** Bug 178337 has been marked as a duplicate of this bug. ***
*** Bug 181152 has been marked as a duplicate of this bug. ***
-> defaults. Darin, can I suggest won't fix for this bug? We have no reports of this problem, and profile migration of 4xp is not a big deal anymore.
i don't know... you'd be surprised. i hear some companies still use 4.x for internal sites, etc. and, this is really easy to fix. i don't mind keeping it as a future bug.
*** Bug 258378 has been marked as a duplicate of this bug. ***
Actually, I found a message while cleaning out my mailbox, which I can't seem to find (or maybe I decided they should just comment in the bug if they really meant it), where they took me to task as an ignorant lout because the original unix preferences were URLs in the environment variable, and these preferences were read from the firing shell when navigator was launched from UNIX. heh. This really should be wontfix for mozilla, and FF can use the new migrator code.
Can I suggest that if this is going to be a WONTFIX, that the direct reference to it in the release notes under Known Issues is removed. I wouldn't have even known about this issue if it wasn't described there. http://www.mozilla.org/releases/mozilla1.7.12/known-issues.html#proxies