From Bugzilla Helper: User-Agent: Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:0.9.8) Gecko/20020204 BuildID: 2002041819 Mozilla doesn't prompt for a username and password when trying to access a proxy auto config script that requires authorisation. This causes proxy configuration to fail silently. Reproducible: Always Steps to Reproduce: 1. Start mozilla on a machine behind the firewall 2. Set the auto proxy config preference to a password protected url. 3. Try to access a webpage outside the firewall Actual Results: Browser fetches auto proxy config file. Authorisation fails, and the browser tries to parse the error message as javascript, causing "syntax error" to appear on the JavaScript console. The browser then tries to fetch the requested page, but the request is blocked by firewall, since the browser tries to go direct rather than using the proxy. Expected Results: Browser fetches automatic proxy config file, asking for authorisation as required. It is then able to fetch the requested page via the automatically configured proxy. If you visit other pages on the same webserver as the proxy auto config script, it'll ask for authorisation. Once given, you can go back into the preferences, click to reload the auto proxy config script, and it'll work as expected. Bug also appears in 0.9.8 on WinNT 4.

-> networking darin: This one looks fun. We need to set a prompter on the channel via nsIInterfaceRequestor, from js, in nsProxyAutoConfig.js::LoadPACFromURL. Do we even have a prompter at this stage of startup? Or should http just fallback to a generic prompter in cases like this?

hmm... how critical is this bug? does it really occur in real world situations? does 4.x get this right? -> me

qa 0> all:all

Navigator 4.7 does get this right, prompting for a username and password the first time it tries to fetch a page from the network. Re this happening in the real world, it's perhaps worth pointing out that Internet Explorer seems able to conspire to pass a Windows NT Domain password to a webserver without troubling the user. Someone might password protect their proxy config without really realising it, or they might just password project everything in sight so they can log who's accessing what.

True, but NTLM is not supported yet, either: bug 23679.

If we cannot fix a lot of PAC stuff, lets release note this and move on to bigger issues...

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

It occurs in reality, as the Bug 168344 has shown. My university has a large number of Sun Ray Station in library, and it seems to me that they are stuck in Netscape 4.7. The university recommended not to upgrade to any Mozilla based browsers simply because of this matter. For some reasons our library do not want to have a PAC accessible by public.

-> moz 1.3 at best.

simple patch. there are still some rough edges, like: 1- would be good if there were an option to automatically send username and password when requesting PAC file. as is, browser startup will be interrupted with a login prompt. 2- the contract for nsIInterfaceRequestor::getInterface requires a NS_NOINTERFACE exception to be thrown if queried for an interface that the implementation cannot provide. this has the unfortunate side-effect of adding two lines to the javascript console at startup. not a big deal, but gives the produce that unpolished feeling.

simple patch. there are still some rough edges, like: 1- would be good if there were an option to automatically send username and password when requesting PAC file. as is, browser startup will be interrupted with a login prompt. 2- the contract for nsIInterfaceRequestor::getInterface requires a NS_NOINTERFACE exception to be thrown if queried for an interface that the implementation cannot provide. this has the unfortunate side-effect of adding two lines to the javascript console at startup. not a big deal, but gives the produce that unpolished feeling.

Comment on attachment 107258 [details] [diff] [review] v1 patch hmm.. bugzilla never complained of a mid-air collision :(

adding testcase (sorry for the internal link)

Comment on attachment 107259 [details] [diff] [review] v1 patch r=bbaetz. The console messages are unfortunate, but I don't think we can help that. Don't worry about the auth dialog; I'm sure theres an rfe somewhere to automatically send save passwords from wallet.

What about writing to Components.returnCode instead of throwing? See http://www.mozilla.org/scriptable/components_object.html#_returnCode

That text talks about 'success' codes, which this isn't. Will anything notice/care?

alternate patch using Component.returnCode. this patch eliminates the javascript exceptions on startup, but i was forced to clear Components.returnCode at the end of LoadPACFromURL since its value seems to be sticky. i wonder if this is a bug in the xpconnect implementation.

dbradley: can you please comment on the use of Components.returnCode in this bug? specifically, see the last three comments. thx!

One last thing, I went to www.cnn.com, started venkman up, set a break point, reloaded the page, close the debugger down, and then closed the browser

And this was really the wrong bug for that comment, sorry.

Sorry for the delay. XPConnect only sets the returnCode when going from JS to XPCOM. It is always set regardless of success/failure. Thus it gets result. If you're going the other way, as appears to be the case here, it's up to the users. Also, ideally you should be setting it to Components.results.NS_OK not 0.

Comment on attachment 107332 [details] [diff] [review] v2 patch: uses Components.returnCode You do want to use Components.results.NS_OK. Also, you want to return null in the failure case, no? Since you're not throwing an actual exception? I'm not sure what I think of that if a JS caller ever calls that code, now that I think about it.... Perhaps comment why we're doing this complicated dance? :(

Comment on attachment 107259 [details] [diff] [review] v1 patch sr=bzbarsky for this if we decide that we don't really care all that much about those JS console messages.

Why would you prefer using 0 in place of NS_OK?

as for 0 vs. NS_OK... i think i was just hacking ;-)

-> suresh

I'm planning to checkin attachment 107259 [details] [diff] [review] (already reviewed and sr'ed) if no one disagrees :)

suresh: i think it would be better to fixup the v2 patch as suggested (See comment #22). thx!

Comment on attachment 118385 [details] [diff] [review] updated patch. >+ Components.returnCode = NS_OK; this line result in the javascript exception: "NS_OK is not defined" maybe this instead: Components.returnCode = Components.results.NS_OK; also, there is a testcase at http://unagi.mcom.com/private/proxy.pac username=foo password=foo

Thanks darin for catching the error. I didn't pay attention to the console :(

Comment on attachment 118469 [details] [diff] [review] updated patch sr=darin

Comment on attachment 118469 [details] [diff] [review] updated patch r=dbradley Was looking around, someone needs to fix this http://lxr.mozilla.org/seamonkey/source/extensions/xml-rpc/src/nsXmlRpcClient.j s#406

fixed in trunk.

suresh: can you just hit nsXmlRpcClient.js#406 while you're at it? thx!

yep, nsXmlRpcClient.js is fixed too!