133108 - PAC: ugly error if PAC fails to load (offer to reload instead)

Status: RESOLVED WORKSFORME

(Core :: Networking, defect)

Description

[David Brittain]

From Bugzilla Helper:
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.8+)
Gecko/20020301
BuildID:    2002030116

On a machine that uses dial-up networking if the browser is started before
connecting to the internet and automatic proxy configuration is set up then it
is not possible to load any pages.


Reproducible: Always
Steps to Reproduce:
1. Start Mozilla
2. Setup automatic proxy configuration (in my case to
http://www.demon.net/www/autoproxy)
3. Close Mozilla.
4. Start Mozilla.
5. Connect to internet via dial-up networking
6. Type a URL in the address bar and press return.


Actual Results:  The browser does not respond and the following error is
displayed in the Javascript console:

Error: LocalFindProxyForURL is not a function
Source File:
file:///C:/Program%20Files/mozilla.org/MozillaLatest99/components/nsProxyAutoConfig.js
Line: 83


Expected Results:  The browser should load the web page.

Networking is functioning correctly otherwise as I can download and news can be
downloaded too.
If the auto configuration is turned off and direct connection used instead then
everything works correctly.

Comment 1

[Peter Trudelle]

->morse.  What is the impact of this on target userbase?  How common is the
combination of dialup and proxy auto-config?  BenC, can QA confirm this is a
problem?

Comment 2

[benc]

Lots of people use PAC, especially corporate customers. I don't know what the
intersection with dial-up usage is, probably very high.

I think we need to do two tests to isolate this further:

1- Confirm PAC loads correctly after the connection is made (use a file:// URL
for the PAC and or use the reload button in the Prefs UI <has not worked well in
the past>)

2- Confirm DNS is not causing the load failure, by putting a IP address in the
PAC URL and testing.

NOTE: this problem is hard to diagnose because PAC is still not robustly
implemented (error messages and reload checking is especially weak).

Comment 3

[David Brittain]

I've tried the two tests:

1) Using PAC reload gets the browser functioning again
2) Using an IP address makes no difference.

Comment 4

[R.K.Aa.]

dup of bug 64857 ?

Comment 5

[David Brittain]

I don't think this is a dupe of that bug as when using an IP address (as the PAC
server name) this doesn't work either.

Comment 6

[benc]

David: how about a summary like: "PAC: does not reload after dialup" ?

This is actually a somwhat serious PAC problem.

Comment 7

[Stephen P. Morse]

I didn't realize there were any PAC bugs still assigned to me.  Reassigning.

Comment 8

[David Brittain]

Fine by me.

Can someone confirm this? It's pretty easy to reproduce. I suspect that you can
get the same effect by unplugging your network cable before browser start-up
when you have PAC enabled.

Comment 9

[Darin Fisher]

->future

Comment 10

[benc]

summary change to reflect real problem.
administrative changes to put this bug back into the eng triage queue (ownership
reset because it isn't apparent to me that Darin should be assigned PAC bugs
automatically.)

Comment 11

[benc]

If a PAC load fails, the javascript console gets the error, and PAC uses
"DIRECT" instead.

If you are on a proxy only network, then this means you are stuck, forever
getting connection errors.

Comment 12

[benc]

-> default owner

Comment 13

[benc]

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

Comment 14

[Mike Connor [:mconnor]]

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

Comment 15

[benc]

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

Comment 16

[Jesiah S]

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

Comment 17

[benc]

If PAC URL is a file: URL, the error is slightly different:

Error: [Exception... "Component returned failure code: 0x80520012
(NS_ERROR_FILE_NOT_FOUND) [nsIChannel.asyncOpen]"  nsresult: "0x80520012
(NS_ERROR_FILE_NOT_FOUND)"  location: "JS frame ::
file:///Applications/Browsers/04-07.app/Contents/MacOS/components/nsProxyAutoConfig.js
:: anonymous :: line 89"  data: no]
Source File:
file:///Applications/Browsers/04-07.app/Contents/MacOS/components/nsProxyAutoConfig.js
Line: 89

Comment 18

[PikeUK]

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

Comment 19

[Laurin Rötzer]

Problem exists still in Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7)
Gecko/20040616.

Any chance to get rid of it?

Comment 20

[Dan Mellem]

I haven't seen this error in a long time. The PAC file still isn't loaded as needed (bug 83984), but I don't think it throws an exception any longer.

Comment 21

[Philip Chee]

Based on Comment 20 => WORKSFORME