353392 - ChatZilla tries to connect before proxy settings are loaded.

Status: RESOLVED FIXED

(Other Applications Graveyard :: ChatZilla, defect)

Description

[Paul Harvey]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.0.7) Gecko/20060909 Firefox/1.5.0.7
Build Identifier: ChatZilla 0.9.75, Firefox 1.5.0.7

When Firefox is not running, launching ChatZilla using a shortcut to  "C:\Program Files\Mozilla Firefox\firefox.exe" -chat  allows ChatZilla to attempt a connection before Firefox proxy settings are loaded (I am using a proxy.pac file in my My Documents folder).

Reproducible: Always

Steps to Reproduce:
1. Set Firefox to use a proxy.pac file which specifies a proxy to connect to.
2. Exit Firefox
3. Launch ChatZilla using a shortcut to "C:\Program Files\Mozilla Firefox\firefox.exe" -chat

Actual Results:  
ChatZilla attempts its first connection without using the proxy, and if the IRC server is inaccessible without the proxy, then the connection is refused. The second connection succeeds.

Expected Results:  
If possible, ChatZilla should wait if the proxy settings have not yet been loaded.

Comment 1

[Paul Harvey]

Note: this is with ChatZilla set to automatically connect on startup.

Comment 2

[James Ross]

I thought Necko blocked connections that might need the proxy until it had loaded the PAC file.

Comment 3

[Paul Harvey]

I've just done a test, and found that the first connection attempt can succeed without using any proxy at all, if the PAC file has not yet loaded.

Comment 4

[Rob Marshall [tH]]

I can reproduce this in Firefox 1.5 and 2.0, but not in 1.0, so it looks to be an ancient core regression. :(

Comment 5

[James Ross]

From what I can see, the PAC Manager returns NS_ERROR_IN_PROGRESS for sync requests to get the proxy info, but will let async ones wait for the PAC file to load. The nsIProtocolProxyService.resolve call catches this and returns a special "unknown" proxy info object (i.e. proxyInfo.type == "unknown").

The object is only scriptable from 2005-03-24 onwards. The unknown type was added on 2005-06-24 (bug 100022).

Basically, it's:
http://bonsai.mozilla.org/cvsblame.cgi?file=mozilla/netwerk/base/public/nsIProtocolProxyService.idl&rev=1.15&mark=98-102#98

The problem is that our connect call must complete syncronously, which is somewhat hard when using nsIProtocolProxyService.asyncResolve.

Comment 6

[:Gijs (he/him)]

(In reply to comment #5)
http://bonsai.mozilla.org/cvsblame.cgi?file=mozilla/netwerk/base/public/nsIProtocolProxyService.idl&rev=1.15&mark=98-102#98
> 
> The problem is that our connect call must complete syncronously, which is
> somewhat hard when using nsIProtocolProxyService.asyncResolve.

We could just show an error/warning and use our progressive backoff reconnect stuff to wait until we do have proxy info? Or am I missing something here?

Comment 7

[James Ross]

Ideally, we would show a [WARNING] (instead of [ERROR]), wait 15s and try the *same* server again.

Comment 8

[James Ross]

Attachment: Display message when PAC is still loading and retry

There's surprisingly little to this patch, ignoring the style tweaks I did. It roughly goes like this: if the proxy is "unknown", it's still loading. So we throw a known exception, which gets caught in CIRCNetwork.prototype.onDoConnect and turned into an onError event. I decided it was better to reconnect in the core, so onDoConnect also initiates the reconnect (using a shorter time and the same host). CIRCNetwork.prototype.onError simply displays the warning message and avoids deleteWhenDone (just in case - we shouldn't end up here with it set, I don't think).

Comment 9

[:Gijs (he/him)]

Comment on attachment 357583 [details] [diff] [review]
Display message when PAC is still loading and retry

OK, this looks good! r=me :-)

Comment 10

[James Ross]

Checked in --> FIXED.