If you think a bug might affect users in the 57 release, please set the correct tracking and status flags for Release Management.

PAC: freezes upon opening while trying to isInNet()

RESOLVED DUPLICATE of bug 208287

Status

()

Core
Networking: HTTP
--
critical
RESOLVED DUPLICATE of bug 208287
15 years ago
14 years ago

People

(Reporter: Mark, Assigned: Darin Fisher)

Tracking

({verifyme})

Trunk
x86
Windows 98
verifyme
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(URL)

(Reporter)

Description

15 years ago
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)

Severity: blocker → critical

Comment 2

14 years ago
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.
(Assignee)

Comment 3

14 years ago
>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

14 years ago
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?
(Assignee)

Comment 5

14 years ago
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

14 years ago
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"
}
(Assignee)

Comment 7

14 years ago
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

14 years ago
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

14 years ago
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

14 years ago
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.
Summary: browser freezes upon opening while trying to resolve DNS → PAC: freezes upon opening while trying to resolve DNS

Comment 11

14 years ago
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

14 years ago
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 ***
Status: UNCONFIRMED → RESOLVED
Last Resolved: 14 years ago
Keywords: verifyme
Resolution: --- → DUPLICATE
Summary: PAC: freezes upon opening while trying to resolve DNS → PAC: freezes upon opening while trying to isInNet()
You need to log in before you can comment on or make changes to this bug.