223759 - Browser won't quit if "router is frozen"

Status: VERIFIED WORKSFORME

(Core :: Networking, defect)

Description

[Klaus-J. Wolf]

User-Agent:       Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.4.1) Gecko/20031015
Build Identifier: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.4.1) Gecko/20031015

(Possible similiarities: Bug #82728, Bug #157472, while probably different
diagnostics)

If the browser starts up with network down (e.g. the router is frozen) it
appears to be sending out DNS requests ("Resolving...") if you enter an URL. But
because the network is down, it'll never get an answer. Pressing Ctrl-Q then
closes all windows, but the mozilla instances never seem to die. They don't even
react on SIGTERM. Even SIGKILL needs a few seconds for them to die, on my machine.

This is especially painful if you don't remember theses instances still
existing, because they make any later calls to a popular mozilla call wrapper
react totally unexpectly (by doing nothing - trying to animate the existing
instance to open a new windows). Under some circumstances, the never-dying
instances seem to eat up all CPU capacity.

Reproducible: Always

Steps to Reproduce:
1. Unplug network (if connected to the Internet by LAN and having a local DNS
proxy).
2. Start mozilla.
3. Type an URL.
4. Type Ctrl-Q.
5. Look at the process list.

Actual Results:  
At least mozilla-bin process remains in the process list.

Expected Results:  
mozilla-bin should die, at least after having received a SIGTERM. It shouldn't
wait for DNS resolution eternally.

Comment 1

[Boris Zbarsky [:bzbarsky]]

Is this an issue with current (1.6a) builds?  The DNS subsystem has been
rewritten since 1.4.

Comment 2

[Christian :Biesinger (don't email me, ping me on IRC)]

-> networking

Comment 3

[Klaus-J. Wolf]

I have only tested Mozilla up to 1.4.1 (which I am currently using).

Comment 4

[Darin Fisher]

worksforme with a recent trunk linux build.  FreeBSD should be no different. 
please test with a trunk build, and reopen this bug report if the problem
persists.  thx!

Comment 5

[benc]

V.
No update for current build, plus the re-write seems to address this architecturally.

Also made summary closer to available problem description.