User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:18.0) Gecko/18.0 Firefox/18.0 Build ID: 20120929030624 Steps to reproduce: This bug is exactly same as bug 771115. looks like it came back again. Nightly is set to use systems proxy. None of the sites are reachable in that case. On setting the same proxy in manual proxy, it works fine. The system proxy is working fine in stable branch. It was working fine in nightly till yday Actual results: Sites timing out when using system proxy. Even sites which are not defined in the proxy.pac in the systems proxy. Expected results: Sites should be accessible when using systems proxy setting.

>On setting the same proxy in manual proxy, it works fine. Does it work if you set the proxy.pac file in Firefox or only if you set the direct proxy address ? We had a bug networking change and it's know the questions if the pac file itself fails or the loading of the system settings. I can confirm that a "alert(myIpAddress()); " isn't triggered in my pac file

this bug report isn't clear to me. Matti - is the complaint that you expect the alert to be triggered and it is not? or is it something else related to the bug mentioned in comment 0? (or are they the same?)

btw if this does boil down to comment 2 that's an awesome minimization of a test case - thanks!

It's not 100% sure that my issue is the same as the reporters one but it's seems to be very likely. reported in comment#0 : regression from yesterday and a pac file pulled via system settings is used on OS X. My testing: pac file over system configuration (win7) or directly configured in Firefox seems to fail. In my case a direct connection is used instead of the SOCKS proxy and the alert in the pac file isn't triggered. and sorry for my Freudian slip in comment#1: s/bug networking/big networking

(In reply to Matthias Versen (Matti) from comment #1) > >On setting the same proxy in manual proxy, it works fine. > Does it work if you set the proxy.pac file in Firefox or only if you set the > direct proxy address ? > I checked and it works for both manual proxy configuration and proxy.pac loaded through automatic proxy configuration url. It is still not working for the system proxy setting though.

I know I tested systems settings with os x 10.6 (and will try again early next week with the final version of what got checked in) - can you think of anything in specific that needs to be checked tat might be different?

Tracking it for 18 and passing on to you Patrick . Feel free to reassign if needed .

Matti - you've uncovered 2 problems here that I don't think are part of this bug.. alert("foo") was implemented as proxyAlert("foo") in the rewrite... that was a misread of the old code on my part. I'll fix it in a different bug dnsResolve("nonexistant.lan") (which is implicit in the implementation if isResolvable()) is throwing an exception instead of returning null.. I'll fix that in a different bug too. neither of these is the anshu's issue though because of comment 6 - the pac file works when directly configured.. Thanks for the issues though - they are valuable edge cases.

Anshu - can you confirm this is a report about OS X 10.7 ? (that's what it says, but it also references a windows specific bug as the 'same thing' and this code is platform specific.)

Anshu - so far this is Works For Me. I have system proxy settings set in the firefox prefs and then in OSX 10.6 system prefs->network I click on airport -> advanced -> proxies and check Automatic Proxy Configuration and I put a pac file in the URL box. (I confirm that file worked ok by earlier setting it directly in firefox). click OK and the Apply. When I do that and go to ipchicken.com I can confirm my proxy setting is honored. Can you do the same test? If it passes what is different about our tests? If nothing sticks out I can can figure out what we need to log.

Quick check : it seems the system proxy was working in yda'ys build. I will need to check it later once am back at home. I moved over to using stable version in b/w due to this bug so can't say when it started working again. Will confirm later today. regards Anshu Prateek

Thanks anshu. I'll mark as WFM for now and you can reopen if necessary.

this is closed and should not be tracked for ff18

Not tracking for FF18 based on comment 14