207652 - PAC: freezes upon opening while trying to isInNet()

Status: RESOLVED DUPLICATE of bug 208287

(Core :: Networking: HTTP, defect)

Description

[Mark]

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.

Comment 1

[Matthias Versen [:Matti]]

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)

Comment 2

[Paul Dundas]

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.

Comment 3

[Darin Fisher]

>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.

Comment 4

[Paul Dundas]

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?

Comment 5

[Darin Fisher]

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.

Comment 6

[Paul Dundas]

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"
}

Comment 7

[Darin Fisher]

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!

Comment 8

[John A.]

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.

Comment 9

[John A.]

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.

Comment 10

[benc]

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.

Comment 11

[Paul Dundas]

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)

Comment 12

[benc]

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 ***