Closed Bug 267023 Opened 20 years ago Closed 19 years ago

Browser hangs for several seconds (up to 1 minute) while resolve DNS name to IP

Categories

(SeaMonkey :: General, defect)

Product:
SeaMonkey
Component:
General
Platform:
x86
Windows XP
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

Status:
RESOLVED DUPLICATE of bug 208287

People

(Reporter: BugHunter, Unassigned)

Details

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; ru-RU; rv:1.7.3) Gecko/20041027 Firefox/1.0RC1
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; ru-RU; rv:1.7.3) Gecko/20041027 Firefox/1.0RC1

While surfing browser very often hangs for short term (from several seconds
up to 1 minute). It's seems to me that it happens while DNS resolving phase.
PS: I'm behind proxy. 

Reproducible: Sometimes
Steps to Reproduce:
1. Just browse and look
2.
3.
Any particular urls? Anything like bug 260832?
(In reply to comment #0)
> PS: I'm behind proxy. 
Then normally the proxy does the DNS resolving.
Assuming that the browser is waiting only for some external service to
resolve a name to an IP number then this bug could be fixed by ensuring
that whilst in this state the status bar showed an an appropriate
message such as:

Resolving http://www.mozilla.org/ or Looking up http://www.mozilla.org/
Contacting http://www.mozilla.org/
Waiting for reply

or whatever.

If there is not a suggestion that the observed behaviour is deviating
from the expected behaviour then this is not a bug.

In fairness, many non-technical people have problems with understanding
what is happening whilst downloading and viewing a web page and its
media, and there is a case for giving fuller messages (the notorious
Microsoft message in IE is an example); but I would have thought that 
most of here would be happy at least for these versions of Firefox
to merely display the correct status messages.
Well, maybe I do not understand all what realy happens.
I've just typed in address bar cnet.ru, pressed Enter, 
and browser hangs for 3 second. 
During this time I was not able to switch to another tab,
press back button, click on other link. Browser was hanging up.
So, what should I think? Where is bug hiding?
IMHO, this is not good behavior. 
My colleges, who really do not know anything about networks, 
services, DNS nerves in this very much.

PS: Reinstallation doesn't help


Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7) Gecko/20040804 Firefox/0.9.3

If you type the words "what really happens when I view a web page" into
the location bar, press return to do an "I'm feeling lucky search", you will
come to a page that explains these points.

The problem you are seeing might be due to your specific set up.

It is not clear that there is any deviation from the expected behaviour,
that is, this is likely not to be a bug.

If you are saying that you would like more feedback, and more detail,
from Firefox as it works, particularly when going through a proxy then 
I can agree with you, but I don't see how this can be done and have 
Firefox retain its present look and feel. We don't want to claim that 
we own the web just because we use its protocols. Clearly something 
could be done to have Firefox give fuller detail of what is going 
on -- training wheels for the web -- but I would be surprised if this 
is ever done and it is certainly not a priority.

In the case of cnet.ru, the lookup happens in under a second and
the entire page loads in about 4 seconds; and I get the status messages
that I expect.

By and large proxies cache DNS lookups quite aggressively, and there
should be no problem whatsoever after the first time you go to a site.
You might want to review your proxy's configuration and check its logs.
Product: Browser → Seamonkey
I can confirm this behaviour on both 
Mozilla/5.0 (X11; U; Linux i686; en-GB; rv:1.7.3) Gecko/20040922
and
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.5) Gecko/20041111 Firefox/1.0
running on Fedora Core 2, 2.6.7 SMP kernel.

In both browsers when I enter a URL (either by bookmark or location bar), if the
browser cannot immediately resove the name then rather than displaying the text
"looking up name...", the whole browser locks up completely until either the
name is resolved or the DNS request times out.  

This means that if I have three browser windows open with 10 tabs each, and a
mail window open, they are all useless until the stalling clears itself.

I would expect the browser to do the name resolution in a separate thread so as
to leave the rest of the session unaffected, and have the text "Looking up name
$name" in the status bar.

To reproduce this bug you would need to have either a slow/dodgy network
connection or an intermittant DNS server, which is often the case in corporate
environments.  On a good network connection+DNS a request will come back with an
answer or error more or less instantaneously, making testing impossible.


I can confirm this behaviour on both 
Mozilla/5.0 (X11; U; Linux i686; en-GB; rv:1.7.3) Gecko/20040922
and
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.5) Gecko/20041111 Firefox/1.0
running on Fedora Core 2, 2.6.7 SMP kernel.

In both browsers when I enter a URL (either by bookmark or location bar), if the
browser cannot immediately resove the name then rather than displaying the text
"looking up name...", the whole browser locks up completely until either the
name is resolved or the DNS request times out.  

This means that if I have three browser windows open with 10 tabs each, and a
mail window open, they are all useless until the stalling clears itself.

I would expect the browser to do the name resolution in a separate thread so as
to leave the rest of the session unaffected, and have the text "Looking up name
$name" in the status bar.

To reproduce this bug you would need to have either a slow/dodgy network
connection or an intermittant DNS server, which is often the case in corporate
environments.  On a good network connection+DNS a request will come back with an
answer or error more or less instantaneously, making testing impossible.


I see this bug in Firefox 1.0.4.  We have a Microsoft ISA proxy server here, and
I'm using Windows XP.  If I watch my machine's traffic, it will attempt DNS
lookups on hosts that don't exist in its cache *before* asking the proxy about
them (ipconfig /flushdns at the commandline will flush this so you can see the
DNS lookups).

I'm a little puzzled as to why DNS lookups need to be made for proxy requests.
are you using a PAC file? it may use things like dnsResolve/isInNet
(In reply to comment #8)

> I'm a little puzzled as to why DNS lookups need to be made for proxy requests.

Simple and easy : this is the dupe of a bug that has been closed and shouldn't
have been  and that was patched with a 60 lines perl or JS script taht is bogus.
If i find out the tainted patch i will try and corect it.

To find it out look for DNS in description, patch in status whiteboard and
resolved closed as status.
Reporter or sufficently empowered   : 

please change Product to Core status white board to Dupe me. HW to all OS to all
and so so if tou understand why. Or else find the dupe and reopen it.
#9: indeed our PAC does use isInNet.  On a whim I set up manual proxy settings,
putting only "localhost" and our domain as hosts to exempt from the proxy, and
DNS resolution is now not happening at all.

Would it be useful to, say, put IP addresses into the exemption list, to force
DNS resolution to happen again, in order to see if it's a problem with the PAC
or not?
(In reply to comment #12)
 

> Would it be useful to, say, put IP addresses into the exemption list, to force
> DNS resolution to happen again, in order to see if it's a problem with the PAC
> or not?

What would be useful is to dupe this bug and reopen the closed bug in which
there is a patch with most probably a queue bug with famine and that dupe this one
(In reply to comment #12)
> Would it be useful to, say, put IP addresses into the exemption list, to force
> DNS resolution to happen again, in order to see if it's a problem with the PAC
> or not?

That wouldn't force DNS resolution. But there's no doubt that it is causing this.


isInNet causing hangs is bug 208287

Yves Lambert: I have no idea what you are talking about, can you mention a bug#?
Though the original reporter has not confirmed that this is a duplicate of
isInNet hanging, I think that's the most likely culprit here.  Alex: please
speak up if I have incorrectly resolved your bug.

*** This bug has been marked as a duplicate of 208287 ***
Status: UNCONFIRMED → RESOLVED
Closed: 19 years ago
Resolution: --- → DUPLICATE
You need to log in before you can comment on or make changes to this bug.