PAC has become too popular for the normal bug handling, so I am declaring new ground rules: If you have a PAC problem and you are not using mozilla 0.9 or later, do not report your problem, upgrade to Mozilla 0.9 or later. If you have a PAC problem with Mozilla 0.9, please see the bug digest I will be adding below. If it does not seem to match, please post a brief description of what is wrong. We will either send you to a bug, or create a new bug. If you have a problem that is already in a bug and you want it fixed, VOTE. If you have a problem that is already in a bug and you want to rant, post in then netlib newsgroup. (If you don't know why I'm saying this, read 53080 and send me a brief summary of the discussion by email).

qa to me. 80363 - MacOS fails.

Starting with nightly 05112001, mozilla will not start if set to use a proxy pac file. 05102001 works fine. It appears to get stuck just after loading the proxy.pac file. 0514200108 segfaults after loading the proxy.pac file. If you set to manual mozilla loads fine. Setting back to proxy.pac after mozilla loads doesn't crash but mozilla ignores any authenication response from proxy server. No request for authentication is presented, just an error saying that authentication is required. clean profile behavior the same.

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

shouldn't the severity be put to blocker since i can't get the ui of mozilla see bug 80664

Michael, Please move your report to a new bug, and look at the aforementioned bug. We'll work it from there.

-->PAC bugs to Jussi

Bug 79371 is the bug for crashes or startup failures.

Serge, can you take a look at these PAC issues? Thanks - Jussi-Pekka

I cannot get a normal file to work as a PAC script. I was using this feature in Netscape 4 to configure the proxies in the various places I access with my laptop. I try to fill in file:///d:/proxy.pac, which works in the browser (it shows me the file), but which has no success ase the autoproxy URL. I am using moz 0.9.2, under Win2K.RFE: How about an error message if the PAC can not be found?

I've asked wmertens@GalaxyCorp.com to file a separate bug on this. FWIW, loading PAC via a file:// has worked for me, at least on Linux, though an alert on failure might be useful.

When I try to use my company's PAC script, I get this error in the JavaScript Console: Error: PrefConfig is not defined Source File: http://config.mcgraw-hill.com.:11111/CONFIG/autoadmin.cgi Line: 211 The first three lines of the PAC script are: * Generated by Netscape Configuration Editor*/ with (PrefConfig) {

I've split this off into bug 91121.

Our company's PAC has *never* worked with Mozilla, and I've only just worked out why. It basically looks like this: function FindProxyForURL(url, host) { if(isPlainHostName(host)) return "DIRECT"; else if(shExpMatch(host, "*.special-internal.com")) return "PROXY webproxy"; else if(shExpMatch(host, "*.normal-internal.com")) return "DIRECT"; else return "PROXY webproxy"; } Mozilla just spins every time it should be hiting the proxy. But it looks fine, and works under NN4 and IE4/5. Only after reading the PAC spec linked to in bug 91121 did I work out that the "PROXY webproxy" should strictly speaking be "PROXY webproxy:80" even though 80 is the default HTTP port. I've made this change to a local copy and it fixes the problem under 0.9.2. So, either this requires a new bug for backwards/sidewards compatability, or it needs documenting so the rest of the world can catch up. I don't think the latter will make Mozilla many friends in the corporate world. :)

I've spun this off as bug 91630.

+ relnote - need to give detailed write up for NS6.1 RTM train.

RELNOTE NS 6.1 I tried to write a draft from the dependecy tree, but it got too messy. I'm going to tag and relnote each bug locally. I'll see if the doc writer will post their first draft in this bug if possible.

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

I reported a bug way back when (27802) about complex PAC files failing to work in Mozilla. Obviously that was an understatement since at the time they didn't work at all :) I've been researching it again and finally came across: <a href="http://www.mozilla.org/docs/netlib/pac.html">http://www.mozilla.org/docs/netlib/pac.html</a> But ... the instructions at the bottom of that page don't seem to work. I don't know if it is an issue with the document, my implementation of the instructions, or maybe 0.9.8 broke the instructions. Guidance on where I should go now would be appreciated as this is my last barrier to giving up Netscape 4.78 (I've given up on Roaming profiles, which was my other "last barrier"). Steps taken: 1) Installed Mozilla 0.9.8 (Win32 on a Windows 2000 laptop) 2) Read the instructions from: http://www.mozilla.org/docs/netlib/pac.html with the following modifications: ----- originally ----- 2) Copy mozilla/netwerk/base/src/nsProxyAutoConfig.js to mozilla/dist/bin/components (this step may not be needed if the file is already installed there!) 3)Edit the nsProxyAutoConfig.js file in mozilla/dist/bin/components directory and remove the sample implementation towards the end of the file starting with the line- //Sample implementation ... ----- modifications ----- ... I didn't have a mozilla/dist/bin/nsProxyAutoConfig.js ... I did have c:\program files\mozilla.org\Mozilla\components\nsProxyAutoConfig.js ... I assumed they were equatable? ... there was no '//Sample implementation ...' in the nsProxyAutoConfig.js file, so I simply appended my 'FindProxyForURL(url, host)' (text of this included at the bottom of this entry) function at the bottom of this file. ----- ----- 3) As instructed I selected the PAC option under preferrences/advances/proxies 4) restarted Mozilla multiple times, made sure that each time I had truly closed Mozilla (I'm using quickstart, so I closed the quickstarted process manually). 5) I never saw the '...Registering Proxy Auto Config' message, but then again unlike under Linux I don't have a nice console to view this on, so it may be happening. ... Questions: a) how can I check under Win32 to see if it has registered the file on loading? b) should this work on Win32? c) where should I look next? ... An example of my PAC file (trimmed down to the needed pieces, it's actually more complicated and I can post the whole bit if it will help ... this version also works in Netscape 4.78 so it's a functional example): function FindProxyForURL(url, host) { // direct to VPN if using subdomain, otherwise use the proxy if (shExpMatch(host.toLowerCase(), "*.(central|corp|west)(|.sun.com)")) { return "DIRECT;"; } else { return "PROXY 192.168.34.1:3128;"; } }

jahf, those instructions are horribly out of date. They were interim instructions until real PAC support landed in Summer 2001. If your version of Mozilla is less than six months old you need only choose Edit/Preferences from the menu, then expand Advanced, and choose Proxies (just like in NS 4.x) and configure things there. Please report any bugs you find in a new bug report. HEY! Please anyone with Mozilla.org write privs receiving this, make those instructions disappear. Better that users stumble on NS 4.x PAC instructions from Google (which will work) than that they read Gagan's hacking tips and rip open Mozilla's guts with a text editor.

Bug 128271. I don't know who will own that, I can provide draft content and technical editing there.

to default owner

taking back PAC...

Temporarily "futuring" all PAC&SOCKS bugs to clear new-networking queue. I will review later. (I promise) If you object, and can make a case for a mozilla 1.0 fix, please reset milestone to "--" or email me.

Here's a list of open PAC bugs not included in the depends-on list above. I don't know if you want to add them in or not. bug 79248 bug 83984 bug 96149 bug 100022 bug 112935 bug 128270 bug 138362 bug 139772

In an effort to see where we stand on PAC issues with regards to the MACH V release, I have compiled a list of all open PAC bugs and classified them by severity. IMO, the only ones that should even be considered for the pending MACH V release are the first two. One is a documentation issue and does not affect the product build. The other is a serious lacking in the product. However the patch is non-trivial and has a high risk associated with it. Therefore it should not be taken at this time. documentation issue: 128270 rudman@netscape.com: update documentation and remove gagan's notes major bugs 84798 morse@netscape.com Failover does not work. minor bugs 78176 new-network-bugs@.. SOCKS return value is not version specific 78436 law@netscape.com PAC files need to be displayed (not loaded) 79244 new-network-bugs@.. myIPAddress() 79248 mscott@netscape.com: mail folders disappear w/ PAC failures 83984 new-network-bugs@.. autoproxy (PAC) should not load at startup 86846 new-network-bugs@.. Cannot display alert() in autproxy config file 90308 morse@netscape.com notify user when PAC can't be loaded (bad url, etc) 91121 new-network-bugs@.. "PrefConfig is not defined" 96149 darin@netscape.com Full URL of proxy required in Moz but not in N4.7 97605 darin@netscape.com PAC execution should not block the UI thread 100022 new-network-bugs@.. connectn to page refused on startup when PAC enabled 112935 morse@netscape.com reload btn obeys proxy settings rather than DIRECT 139772 darin@netscape.com HTTP auth support enhancements 79242 serge@netscape.com isInNet function needs to support new addressing 89928 new-network-bugs@.. PAC overhaul (use PAC for everything) 97607 new-network-bugs@.. PAC2: directive for HTTP version 138362 new-network-bugs@.. using PAC for ad-blocking (skoonce@usc.edu's file)

Absent any marketing feedback, I vote for fixing failover and calling it a day. If you want to actually make it workable, you need to do a compatability review of the functional calls with 4xp. The lack of robust error handling makes working in this area (esp. testing) quite horrible and time consuming. If you want to make it usable, there are several major UI problems that need to be fixed, maybe someone who does a lot of UI could be brought in for quick fixes. As for QA, who's group do you work for. I don't know if QA officially considers this a networking feature anymore.

Development on this is now owned by the Navigator team, though I'm not aware that any change in QA ownership goes along with it.

I vote for implementing it correctly, along the lines of Netscape 4.7x functionality. Clear out the underbrush, knock it out.

I vote for implementing it correctly, along the lines of Netscape 4.7x functionality. Clear out the underbrush, knock it out. In a related incident to comment #13: Our proxy.pac file is loaded as: http://internal.server/path/proxy.pac (pretty generic) function FindProxyForURL(url, host) { if (dnsDomainIs(host,"internal")) { return "DIRECT"; } else if (isInNet(myIpAddress(),"192.168.0.0","255.255.255.0")) { return "PROXY proxy1.internal:3128; PROXY proxy2.internal:3128; DIRECT"; } else return "DIRECT"; } In this file I respect the specs with host:port. Mozilla 1.2b behaviour: always uses DIRECT.

(we have a PAC failover bug, so please put the technical discussion in bug 84798)

I have a similar problem with Mozilla 1.3(Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.3) Gecko/20030312) At first a part of my proxy.pac file: ---- function FindProxyForURL (url, host) { if ( shExpMatch(url,"http:*") || shExpMatch(url,"ftp:*")) { return "PROXY xxx.xxx.245.147:8080; PROXY xxx.xxx.247.178:8080; DIRECT"; } ----- Instead the xxx are the real IP of my company ;-) . If the first proxy is up, Mozilla works well. If the first proxy is down, the second proxy should answer. But with Mozilla 1.3 it dosn't work (displays "Operation timed out when atempting to contact www.bochum.de"). With Netcape 7.x and MS Expl6 it works. Both proxy works correctly. Reproducibility: Everytime when first proxy is down. Any first hint?

Comment #31 says Netscape 7.x works with proxy failover. Isn't Netscape 7 still based on Mozilla? Then they fixed this in their branch (which I'm sure it's older then Mozilla-1.3) while Mozilla still has this bug...

To my knowledge, this doesn't work in Mozilla 1.0.0 nor Netscape 7. I just tested it again and verified w/ a network trace.

I really found a workaround for this problem: Use your wpad.pac file like this: function FindProxyForURL(url, host) { if (isResolvable(host) { <... your stuff ...> } else return "DIRECT"; } This works for me... Greets Sascha

tracking bug that is no longer up to date