Automatic proxy configuration URL doesn't work - Regression since 2005083006 Nightly

RESOLVED FIXED

Status

()

Core
Networking
--
blocker
RESOLVED FIXED
13 years ago
13 years ago

People

(Reporter: Mike Mason, Assigned: mrbkap)

Tracking

({regression, verified1.8})

1.8 Branch
x86
Windows XP
regression, verified1.8
Points:
---
Bug Flags:
blocking1.8b5 +

Firefox Tracking Flags

(Not tracked)

Details

(URL)

Attachments

(1 attachment)

(Reporter)

Description

13 years ago
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
Status: UNCONFIRMED → NEW
Ever confirmed: true
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
Assignee: nobody → darin
QA Contact: build.config → benc

Comment 4

13 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.
Flags: blocking1.8b4?
Keywords: regression
mrbkap, are you able to test this?  Can someone set up a testcase?

/be
Flags: blocking1.8b4? → blocking1.8b4+

Comment 6

13 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

13 years ago
Created attachment 194379 [details] [diff] [review]
fix security checks

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 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

13 years ago
Fix checked into MOZILLA_1_8_BRANCH and trunk.
Status: NEW → RESOLVED
Last Resolved: 13 years ago
Keywords: fixed1.8
Resolution: --- → FIXED

Comment 10

13 years ago
*** Bug 306618 has been marked as a duplicate of this bug. ***
I'm not 100% certain I'm testing this correctly.

Reporter, please verify.
(Reporter)

Comment 12

13 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.