Closed
Bug 306467
Opened 19 years ago
Closed 19 years ago
Automatic proxy configuration URL doesn't work - Regression since 2005083006 Nightly
Categories
(Core :: Networking, defect)
Tracking
()
RESOLVED
FIXED
People
(Reporter: TechMason, Assigned: mrbkap)
References
()
Details
(Keywords: regression, verified1.8)
Attachments
(1 file)
5.64 KB,
patch
|
brendan
:
review+
brendan
:
superreview+
brendan
:
approval1.8b4+
|
Details | Diff | Splinter Review |
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.
Comment 1•19 years ago
|
||
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
Status: UNCONFIRMED → NEW
Ever confirmed: true
Comment 2•19 years ago
|
||
Problem also occurs with: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a1) Gecko/20050830 SeaMonkey/1.1a
Component: Build Config → Networking
Product: Firefox → Core
Version: unspecified → Trunk
Updated•19 years ago
|
Assignee: nobody → darin
QA Contact: build.config → benc
Comment 3•19 years ago
|
||
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
Comment 4•19 years ago
|
||
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.
Updated•19 years ago
|
Flags: blocking1.8b4?
Keywords: regression
Comment 5•19 years ago
|
||
mrbkap, are you able to test this? Can someone set up a testcase? /be
Flags: blocking1.8b4? → blocking1.8b4+
Comment 6•19 years ago
|
||
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
Assignee: darin → mrbkap
Severity: major → blocker
Version: Trunk → 1.8 Branch
Assignee | ||
Comment 7•19 years ago
|
||
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).
Attachment #194379 -
Flags: review?(brendan)
Comment 8•19 years ago
|
||
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
Attachment #194379 -
Flags: superreview+
Attachment #194379 -
Flags: review?(brendan)
Attachment #194379 -
Flags: review+
Attachment #194379 -
Flags: approval1.8b4+
Assignee | ||
Comment 9•19 years ago
|
||
Fix checked into MOZILLA_1_8_BRANCH and trunk.
Comment 10•19 years ago
|
||
*** Bug 306618 has been marked as a duplicate of this bug. ***
Comment 11•19 years ago
|
||
I'm not 100% certain I'm testing this correctly. Reporter, please verify.
Reporter | ||
Comment 12•19 years ago
|
||
(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
Keywords: fixed1.8 → verified1.8
You need to log in
before you can comment on or make changes to this bug.
Description
•