Just downloaded Mozilla 0.9 Configured up the auto-proxy stuff, and it works a treat. However, when I shut-down mozilla and re-start it, Mozilla Dr. Watsons on me. If I go and manually edit the prefs.js file to remove the two lines relating to proxy configuration, then mozilla starts fine. If I put in manual proxy configuration, then mozilla also starts fine. Before I installed Mozilla 0.9, I deleted mozregistry.dat & the Mozilla directory in the "Application Data" directory. I've install Mozilla on another machine, but I can't reproduce the problem.

Can you attach the Dr Watson's log from the crash and or the talkback id from the crash? thanks in advance.

I've submitted the Dr. Watson log. I have sent a couple of talkbacks, but I don't know the IDs (sorry) Just found out one other thing... If you configure proxies using manual, then switch to auto-configure (without deleting manual entries) Mozilla starts up. If you go back to prefs.js and delete the manual proxy entries, Mozilla then fails to start.

qa to me. WFM: I have not seen a crashing problem w/ PAC like this. What entries did you delete from prefs.js? Do you mean you deleted "network.proxy.type" as well?

Perhaps related: regardless if manual proxy settings have been filled in, if auto proxy config is used, Moz (build 2001051004 (IIRC) and later on Win98) fails to work. It doesn't crash, but start up takes about 30 seconds (instead of 5) and results in a tiny window that consists of a titlebar empty except for the Mozilla icon and the min/max/close icons and there is no content area. The window can be dragged out, but the content area is not drawn. Attempting to load Moz again (which should open a new browser window) opens up a chromeless window with an error message from my proxy saying that it cannot fetch "chrome://navigator/content/". Resetting prefs back to manual proxy config allows Moz to work again. It looks like setting auto proxy config stops Moz from loading its chrome.

When deleting the auto-proxy config, I delete the following two lines from prefs.js user_pref("network.proxy.type", 2); user_pref("network.proxy.autoconfig_url", "http://proxy-cfg.ccw.gov.uk:1959/data/proxy.pac"); If I leave in all the "manual" entries (network.proxy.ftp, network.proxy.gopher, etc) then Mozilla will start up with proxy-autoconfig enabled.

Now having a problem with 2001051704 Win98 build - crashes in DOCSHELL.DLL. I've posted a report in bug 80644. (Is this a dupe?)

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

keywords: +[crash,nsbeta1,nsdogfood] status=new Need to fix this for nsbeta1, can't test b/c its dogfood, mostfreq b/c have LITMUS TEST: If you set the proxy type to direct or manual in prefs, and the problem goes away (or delete the "network.proxy.type" line in prefs.js), you have this problem. If you have crash data, please file a new bug and dupe in. If you are affected by have no crash data, please VOTE rather than create a new bug.

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

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

Blocking bug 79893, and setting priority to P1.

PAC bugs to jpm

this crash is showing up in the latest talkback topcrash reports under the docshell.dll and nsDocShell::DoURILoad stack signatures. adding topcrash keyword and Trunk [@ nsDocShell::DoURILoad] to summary for tracking. Here are a couple of entries and a stack trace: nsDocShell::DoURILoad 4b53016c http://bonsai.mozilla.org/cvsblame.cgi?file=mozilla/docshell/base/nsDocShell.cpp line 3961 Build: 2001051710 CrashDate: 2001-05-17 UptimeMinutes: 0 Total: 8 OS: Windows 98 4.10 build 67766222 Detailed : http://climate/reports/incidenttemplate.cfm?bbid=30587953 StackTrace: http://climate/reports/stackcommentemail.cfm?dynamicBBID=30587953 (30587953) Comments: open mozilla with auto proxy config set. nsDocShell::DoURILoad 4b53016c http://bonsai.mozilla.org/cvsblame.cgi?file=mozilla/docshell/base/nsDocShell.cpp line 3961 Build: 2001051710 CrashDate: 2001-05-17 UptimeMinutes: 0 Total: 8 OS: Windows 98 4.10 build 67766222 Detailed : http://climate/reports/incidenttemplate.cfm?bbid=30587874 StackTrace: http://climate/reports/stackcommentemail.cfm?dynamicBBID=30587874 (30587874) Comments: load mozilla (auto proxy config set) Incident ID 30587874 nsDocShell::DoURILoad [d:\builds\seamonkey\mozilla\docshell\base\nsDocShell.cpp, line 3961] nsDocShell::InternalLoad [d:\builds\seamonkey\mozilla\docshell\base\nsDocShell.cpp, line 3864] nsDocShell::LoadURI [d:\builds\seamonkey\mozilla\docshell\base\nsDocShell.cpp, line 531] nsDocShell::LoadURI [d:\builds\seamonkey\mozilla\docshell\base\nsDocShell.cpp, line 2025] nsWebShellWindow::Initialize [d:\builds\seamonkey\mozilla\xpfe\appshell\src\nsWebShellWindow.cpp, line 327] nsAppShellService::JustCreateTopWindow [d:\builds\seamonkey\mozilla\xpfe\appshell\src\nsAppShellService.cpp, line 662] nsAppShellService::CreateHiddenWindow [d:\builds\seamonkey\mozilla\xpfe\appshell\src\nsAppShellService.cpp, line 235] main1 [d:\builds\seamonkey\mozilla\xpfe\bootstrap\nsAppRunner.cpp, line 993] main [d:\builds\seamonkey\mozilla\xpfe\bootstrap\nsAppRunner.cpp, line 1311] WinMain [d:\builds\seamonkey\mozilla\xpfe\bootstrap\nsAppRunner.cpp, line 1329] WinMainCRTStartup() KERNEL32.DLL + 0x1b537 (0xbff8b537) KERNEL32.DLL + 0x1b3e9 (0xbff8b3e9) KERNEL32.DLL + 0x19dac (0xbff89dac)

+lisa and gagan to cc. I'd like to know that this is assigned to the right person (is it jpm)? and get a milestone and nsbeta1 nomination triaged.

send email to jpm to make sure he is the right owner. This is a topcrash which would be good to fix.

Over to Serge. Serge, let's help CPD ship this puppy! :-) Adding mozilla0.9.1 nomination.

Reassigning.

Hmmm... I wont be surprised if my patch to bug 81214 fixes this as well. Serge make sure you try that patch before investigating on this one.

Setting this to M0.9.1. PDT will look at this again on Friday.

I'm unable to reproduce the crash with 2001052406 linux & win32 builds. but I'm getting "connection refused" alert for Proxy = = DIRECT, and there is a bug#82541 about it.

I am getting the following console message from a WinNT Debug CVS Build from 11am EST: ************************************************************ * Call to xpconnect wrapped JSObject produced this error: * [Exception... "'[JavaScript Error: "LocalFindProxyForURL is not a function" {file: "C:\Projects\mozilla\dist\WIN32_D.OBJ\bin\compone nts\nsProxyAutoConfig.js" line: 72}]' when calling method: [nsIProxyAutoConfig::ProxyForURL]" nsresult: "0x80570021 (NS_ERROR_XPC_J AVASCRIPT_ERROR_WITH_DETAILS)" location: "JS frame :: chrome://navigator/content/navigator.js :: BrowserReloadWithFlags :: line 526 " data: yes] ************************************************************ I have both Manual Proxy and Auto Proxy entered in the preferences and switching from Manual to Auto gives this error.

There is no such error for file:/// scheme of pac url, though I'm getting it for http:// scheme, probably this is security issue in evalInSandbox() call

here is the patch: http://bugzilla.mozilla.org/showattachment.cgi?attach_id=36223 gagan, darin could you please take a look and r=/sr= if there is no objection? thanks.

argh....! this is exactly the reason why I had commented in a review on bug 53080's patch that -- "the default value on proxy ports as in all.js is zero. I had filed a bug long time back but haven't seen much progress on it with shifting prefs-owners. This is why the check for proxyPort>0 was required. Till that happens (and I might just do that myself) it might be a good idea to leave the check for ports>0 when we fetch the prefs." sad to see that it manifested itself as this bug... The correct fix in my mind is still on that level (nsProtocolProxyService) though I'd leave the additional check in HTTP for a zero proxy port. With that r=gagan and darin should still review the "direct" portion.

Summarize: The crash in nsDocShell::DoURILoad was fixed somehow before this bug wag assigned to me, at least I was never able to reproduce the crash... The patch is the same as the second one for bug 82541, which has sr==darin/r=gagan, and correct indentation. It fixes proxy==DIRECT problem, as well as [JavaScript Error: "LocalFindProxyForURL is not a function" . I'm posting it here to document what actually is going to be checked in, after check in I'm going to mark bug 82541 as a dup of this one.

a= asa@mozilla.org for checkin to 0.9.1 (on behalf of drivers)

Checked in ... /cvsroot/mozilla/netwerk/base/src/nsProtocolProxyService.cpp,v <-- ... new revision: 1.23; previous revision: 1.22

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

Is this a dupe b/c one patch fixes two bugs?

yes, the patch fixes two bugs, so I've marked 82541 as a dup.

That messes up the way we do verifications. You only need to refernce the patch in the other bug.