User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows 98) Build Identifier: latest "stable" release. can't get it to not freeze upon opening the app Browser freezes while trying to resolve DNS upon opening. Reproducible: Always Steps to Reproduce: 1.Click on desktop icon to launch Mozilla 2.Window opens, then browser stops while resolving DNS 3. Actual Results: Control+Alt+Delete to shut down the application Expected Results: umm, not freeze? No themes, no nothing, just downloaded the browser, installed, and tried to access the internet with it.

Have you installed Mozilla in a empty directory and not over an older build ? (that means: deinstalled Mozilla, deleted the whole application directory except the plugins subfolder and installed the new Mozilla)

I get a similar problem Moz 1.4, 1.5 (and possibly earlier... can't remember exactly how long). If I type a non-existent address into the URL bar and hit return, all mozilla windows stop responding, won't redraw, etc. Today I noticed that if I leave it long enough (minutes), the browser reawakend with an error from our local proxies. Running Win XP Pro, Installation of mozilla "into clean directory" (ie. didn't uninstall, but used different target directory), Auto Proxying enabled (from a http://..../default.pac url). Followup: back-buttoned to check the wording of the error, and replicated behaviour: 1. Browser stoppen responding, screen repainted when covered/uncovered by other windows. If window resized, original extent of window repainted, scrollbars etc not redrawn in new position - stuff hidden if window shrunk / white space if window expanded. 2. After minute or so, XP marked app "not responding" in title bar. Redrawing now limited to portion of window not obscured by other windows at that moment. The bits obscured behind the active window repainted in white. 3. I invoked task manager - application list showed two mozilla entries, but no large CPU use. Blocked rather than tightly looping? 4. After a minute or so, it came back, and I typed this text. FYI, proxy error was ("The requested item could not be loaded by the proxy. Proxy server is unable to locate the server: v. The server does not have a DNS entry. Check the server name in the Location (URL) and try again.") I'll try to replicate this later without a proxy, and/or on W98 if that is considered helpful.

>Auto Proxying enabled ah!! and, does your PAC file call isInNet or isResolvable? these will block the main mozilla thread until the host lookup completes.

How would I find out? http-get the .pac file and read it? Don't understand this in detail, but is it ever OK for a browwser to hang for as long as this? Given that end-users in the company don't control this file (and it's pretty much required, since the real proxies could keep moving, and most users don't know how to manually identify and conf the real proxies), can mozilla be made more resistant to blocking due to such "carefully crafted" proxy setup? After all, IE doesn't freeze with the same proxy definitions, and freezing is not desirable behaviour... If true, this is potentially a widespread problem which would not easily be detected back at mozilla "hq". No auto feedback... just users concluding mozilla is broken... Can anyone confirm? Is this a known issue?

please just load the pac url in mozilla and look for the presence of those two functions i mentioned. i would like to confirm that those functions are the problem before marking this bug as a duplicate of _that_ well known problem. thx.

Yes - the isInNet function is present. The default.pac contains a variety of lines of the form: function FindProxyForURL(url,host) { .... if ( (shExpMatch(host, "*.2.example.com"))|| (shExpMatch(host, "*.3.example.com"))|| (isInNet(host, "10.0.0.0", "255.0.0.0"))|| (isInNet(host, "192.168.3.0", "255.255.255.0"))|| (shExpMatch(host, "foo.4.example.com"))|| (shExpMatch(host, "foobar*.4.example.com"))|| (shExpMatch(host, "foo.5.example.com/foo"))|| (localHostOrDomainIs(host, "foo.6.example.com"))|| (localHostOrDomainIs(host, "localhost")) ) { return "DIRECT" } if ( (isInNet(host, "172.16.1.1", "255.255.255.255"))|| (localHostOrDomainIs(host, "foo.7.example.com"))|| (shExpMatch(host, "*.foobar.7.example.com")) ) { return "PROXY foofoo.example.com:8080; DIRECT" } return "PROXY fffoo.example.com:8080; PROXY bbbar.example.com:8080; DIRECT" }

yup, that's what i figured. hmm... paul: can you please give 1.6 alpha a try and let me know if it has the same problem? thx!

I've been having this problem as well with 1.5RC1 and no-ads.pac (http://www.schooner.com/~loverso/no-ads/) I guess I'll take a look through it and see what can be changed. Not exactly an old hand with Javascript, so if anyone else cares to hack at it, be my guest. Any luck with 1.6b? I had a GDI system crash my first day using it, so I've switched back to 1.5RC1.

Okay. I fixed my copy of no-ads.pac by remarking out a few lines that filtered out whole subnets (and adding one close-paren to replace one lost in the remarking.) The site I was having trouble with (www.pgdp.net, which is having DNS troubles, hopefully temporarily) just gives a DNS timeout message after a few seconds, and doesn't lock up the system while waiting for that. I'd still like to see this fixed. Some folks don't have the access and/or ability to edit their pac file.

I'm not certain the initial description is the same Pauls problem, but I think we've morphed, so I updated the summary. isInNet() causes your browser to resolve every hostname. That in itself is not incredibly slow, but environmental factors like firewalls and domain naming conventions can make it very slow. There are actually a couple, related issues here. 1- You probably got a proxy version of bug 65924. I've never tested the case of that bug via proxy, but it is the logical inference. 2- Your PAC file is not very efficient in all cases. It looks like you go through isInNet() several times. I don't know how PAC interacts w/ DNS cache, but Darin probably knows. 3- Is the behavior worse in 1.6x than previous versions. Nobody has complained in a while, which suggests a combination of: a) People who had really badly designed PAC files had removed the "bad functions" b) People who had the bad functions operated in environments where they didn't notice or complain.

I have seen the same problem with 1.6 - though not so often. Maybe my typing is improving :) (and the centrally managed .pac file is actually much "worse than that" - I summarised)

RESOLVED/DUPE. Please confirm. If there are problems post-Mozilla 1.6, please file a new bug. Preferably use 1.7RC1 or later, b/c Darin had two important re-writes of DNS cache and PAC usage of DNS cache. *** This bug has been marked as a duplicate of 208287 ***