User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8b4) Gecko/20050830 Firefox/1.0+ Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8b4) Gecko/20050830 Firefox/1.0+ "Automatic proxy configuration URL" no longer works since I updated to the 2005083006 Nightly. It seems that Fx doesn't even read the URL http://mysite.com/proxy.pac. Local sites are available but anything that must use the proxy server doesn't. Fx is trying to contact the destination sites directly as if there were no proxy configuration at all. Reproducible: Always Steps to Reproduce: 1. Use a Automatic proxy configuration URL i.e. http://mysite.com/proxy.pac file 2. Try browsing to a site that should use a proxy server (from the .pac) Actual Results: Fx tries to directly access the destination URL Expected Results: Fx should talk to the proxy server (specified in the .pac file) to request the data.

Confirming with Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a1) Gecko/20050830 Firefox/1.6a1 Works fine with Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a1) Gecko/20050829 Firefox/1.6a1

Problem also occurs with: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a1) Gecko/20050830 SeaMonkey/1.1a

I suspect this checkin: http://tinderbox.mozilla.org/bonsai/cvsquery.cgi?module=PhoenixTinderbox&branch=HEAD&cvsroot=/cvsroot&date=explicit&mindate=1125361724&maxdate=1125362101&who=darin%25meer.net

Bill: that checkin has nothing to do with firefox. it only applies to some test files that are not part of the distribution. i recall seeing some changes to the XPConnect sandbox API going by recently, and so i think those might be suspect here. I wonder if the changes for bug 302834 could have caused this.

mrbkap, are you able to test this? Can someone set up a testcase? /be

OK, I setup a testcase here: http://friedfish.homeip.net/~darinf/proxy.pac This PAC file makes it so that www.mozilla.org gets routed through a non-existant proxy server. I noticed in my debug build that loading this PAC file results in the following error: ************************************************************ * Call to xpconnect wrapped JSObject produced this error: * [Exception... "Component returned failure code: 0x8007000e (NS_ERROR_OUT_OF_MEMORY) [nsIXPCComponents_Utils.evalInSandbox]" nsresult: "0x8007000e (NS_ERROR_OUT_OF_MEMORY)" location: "JS frame :: file:///builds/moz-1-8-branch/ffox-debug-build/dist/bin/components/nsProxyAutoConfig.js :: anonymous :: line 82" data: no] ************************************************************ -> mrbkap

The problem was that we needed an object in the private data that implemented nsIScriptObjectPrincipal (and the additional class flag that tells us that our private data was an nsISupports). This introduces the PrincipalHolder, which QIs to all of the right interfaces and makes caps much happier (to the point of letting PAC work, even).

Comment on attachment 194379 [details] [diff] [review] fix security checks r+sr=me, with the impossible NS_RELEASE after JS_SetPrivate fails code you added already ;-). a=me too -- PAC must work, we really should have test automation for it in tinderboxes. /be

Fix checked into MOZILLA_1_8_BRANCH and trunk.

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

I'm not 100% certain I'm testing this correctly. Reporter, please verify.

(In reply to comment #11) It works fine now. Thank you for the quick fix. Using Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8b4) Gecko/20050901 Firefox/1.0+ ID:2005090106

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8b5) Gecko/20051003 Firefox/1.4.1 verified fixed