User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.5) Gecko/20041107 Harrison Conference Center at Glen Cove/1.0 Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.5) Gecko/20041107 Harrison Conference Center at Glen Cove/1.0 Firefox is setup to use a Squid proxy server. I attempt to visit a non-existant domain that will bring up a DNS error on the proxy server. The moment between me submiting the address and the proxy server returning the error, Firefox locks up the system. I am unable to switch to SOME other running programs, click the task bar, or cancel the request. Firefox and SOME other programs become un-responsive. The computer has not completly locked up, but only certian application (for example Thunderbird) will not respond in addition to Firefox. It is not until the proxy server returns the error that I am able to continue working normaly. Reproducible: Always Steps to Reproduce: 1. Open Firefox 2. Open some other Application (for example Thunderbird) 3. Set firefox to use a proxy server (tested with Squid running on FreeBSD) 4. Visit a not existant domain (for example www.fooo.nothing) 5. Submit Request. Actual Results: 1. Firefox locks up the system, you are unable to activate Thunderbird. 2. Once proxy returns error the system is back to normal Expected Results: Firefox should not lockup the system and should allow me to switch to other programs during the DNS look up period, or allow me to cancel the request. May be related to bug #274506 - Cannot Stop a DNS lookup.

This happens to me all the time at work. To make matters worse, sometimes it appears that the proxy server forgets to ever send an error, meaning that Firefox freezes forever and must be killed. Interestingly, IE exhibits the exact same behavior. Needless to say, this is a huge annoyance; a typo in the address bar results in a frustrating wait to see if Firefox will recover and occasionally work is lost. Fixing this bug would give Firefox a big advantage over IE in my office.

I was troubled by this problem for quite a while. nslookup result shows that the non-existant address can still be resolved very quickly. Even if it can't be resolved very soon, it is highly desirable that the long dns lookup delay should not affect other applications, say Thunderbird, other FX windows, and even other tabs in the current FX window. IE has at least one advantage now: if one IE window becomes not responding, a second one can be opened for browsing. Hope to see this problem fixed soon. Typos in location bar can happen so frequently that the browser should deal with this very well.

Here what happens to me. When opening multiple tabs (for instance after a google search), when an host is not resolvable, firefox hangs completely. When the message "server not found" appears, everything is working back again. mozilla-firefox-1.5.0.1 Here is the stack trace of 2 threads: the dns one: #0 in poll () from /lib/libc.so.6 #1 in __res_queriesmatch () from /lib/libresolv.so.2 #2 in __libc_res_nquery () from /lib/libresolv.so.2 #3 in __res_nquery () from /lib/libresolv.so.2 #4 in __libc_res_nsearch () from /lib/libresolv.so.2 #5 in _nss_dns_gethostbyname3_r () from /lib/libnss_dns.so.2 #6 in _nss_dns_gethostbyname2_r () from /lib/libnss_dns.so.2 #7 in sched_setaffinity () from /lib/libc.so.6 #8 in getaddrinfo () from /lib/libc.so.6 #9 in PR_GetAddrInfoByName () from /usr/lib64/nspr/libnspr4.so.6 #10 in CopyUCS2toASCII () from /usr/lib64/mozilla-firefox/components/libnecko.so #11 in PR_Select () from /usr/lib64/nspr/libnspr4.so.6 #12 in pthread_start_thread () from /lib/libpthread.so.0 #13 in clone () from /lib/libc.so.6 the main frozen thread: #0 in __pthread_sigsuspend () from /lib/libpthread.so.0 #1 in __pthread_wait_for_restart_signal () from /lib/libpthread.so.0 #2 in pthread_cond_wait@GLIBC_2.2.5 () from /lib/libpthread.so.0 #3 in PR_WaitCondVar () from /usr/lib64/nspr/libnspr4.so.6 #4 in PR_Wait () from /usr/lib64/nspr/libnspr4.so.6 #5 in CopyUCS2toASCII () from /usr/lib64/mozilla-firefox/components/libnecko.so #6 in XPTC_InvokeByIndex () from /usr/lib64/mozilla-firefox/libxpcom_core.so #7 in nsSupportsArray::AppendElement () from /usr/lib64/mozilla-firefox/components/libxpconnect.so #8 in nsSupportsArray::AppendElement () from /usr/lib64/mozilla-firefox/components/libxpconnect.so #9 in js_Invoke () from /usr/lib64/mozilla-firefox/libmozjs.so #10 in js_FreeStack () from /usr/lib64/mozilla-firefox/libmozjs.so #11 in js_Invoke () from /usr/lib64/mozilla-firefox/libmozjs.so [..]

Suggested resolution: DNS lookups should be asynchronous. After searching through the bug database for "DNS lookup" I have noticed that there are a lot of issues with DNS lookups that would all be resolved if the client didn't block while waiting for a DNS lookup to complete. There appear to be a number of ways to reproduce this issue from proxy servers to broken DNS records to simply slow network connections. If the client were to continue to function while resolving a domain name users would then be able to: A) Cancel the DNS lookup when they mistype an address. B) Continue browsing other pages when a DNS lookup is taking a while. C) Continue browsing a website when an advertisement or other external link on the page doesn't resolve. D) Prevent a crash when a DNS lookup fails to return at all (for any reason).

Should a different (meta-) bug be filed for (fully) implementing async dns lookup? It seems like it was already partially implemented for mac and win32, but not for unix? (see 10731 [mac], 10732 [win]). Could someone comment on this please? Note that I'm seeing this bug happen even without using a proxy in ff on Linux. It is particularily annoying when I surf in one tab and suddenly the browser freezes because lookups are performed in background in another tab (seemingly for background xmlhttp requests). The following bugs also seem to be related: bug 274506 (cannot stop a dns lookup) bug 234320 (lookups take very long time for DNS server on same LAN)

so, this one is clearly the wrong bug if people are seeing issues without using a proxy. as for blocking while waiting on DNS queries, in theory DNS queries are async on all platforms, the code is there and believed to be working. (it does work for me, certainly)

I experience this issue with Firefox 1.5.0.3 on Windows XP SP2 as well as everyone else here at my office. Internet Explorer has the same problem though each IE window runs in it's own process so one window won't lock up another window (though each window will fully lock itself up). My office is behind a proxy and I will admit that I do not have conclusive proof that it is the DNS lookups that are hanging it but the problem only occurs when browsing to a new site/obscure site (a domain that isn't cached). If I browse to a new site the initial load locks up (presumably while doing the DNS query) and every page load from that domain after that is quick for some time. If I do not access that site for a while eventually it will lock up on the initial load again. Due to these symptoms I'm lead to believe that it's the DNS lookup causing the lockup though it could be something else revolving around going to a new site.

I get same error - very very annoying behaviour. I am using FF 1.5.0.7 on Mac OS X 10.4 and similar error on Linux (Fedora). I use both with and without proxy servers (at different locations) and error occurs everywhere. Worse on Mac than linux (longer delay, harder to kill). This is the most painful part of FF so far. Must be fixed soon to prevent us all switching.

I recently got my computer setup at work to bypass our proxy server (for another reason) and Firefox no longer locks up when going to an invalid domain name such as www.googlec.om or other such typo.

I use firefox almost everyday, and for me this is the most annoying bug by far.

This seams to be a dup of bug #235853

anyone with this problem can tell me if you have a "automatic proxy configuration" or the "auto-detect proxy setting" turn on? or this also happens with a manual proxy server? to be dupe from bug #235853 , you need a .pac file. on my machine, with manual proxy, accessing a unknown domain will not freeze firefox.

I've tried to reproduce the bug. UI freezes only in case when hostname is resolved in PAC file (i.e. duplicate of #235853). I've tried accessing nonexistent domain in following scenarios. OK means that UI didn't freeze even if request took long time to fail. 1) No proxy (mentioned in comment #8 as problematic too) - Fully working DNS : OK - DNS dropping some packets (resolving takes long time) : OK - DNS inaccessible : OK 2) Manual Proxy setting No DNS query is performed by FF at all. Request is sent to proxy without resolving. - Squid can resolve : OK - Squid can't resolve : OK 3) Automatic proxy configuration URL Used local PAC file and FindProxyForURL() uses dnsResolve(). - Fully working DNS : freezes UI for few seconds - DNS dropping some packets : freezes UI for the duration of call to dnsResolve() - DNS inaccessible : freezes UI for the duration of call to dnsResolve() 4) Auto-detect proxy - fully working DNS and no wpad domain : OK wpad domain exists but no wpad.dat file present : OK wpad.dat with dnsResolve() : freezes UI for few seconds - DNS dropping some packets and no wpad domain : OK wpad domain exists but no wpad.dat file present : OK wpad.dat with dnsResolve() : freezes UI for the duration of call to dnsResolve() - DNS inaccessible : OK I've also tried to find all calls to nsIDNSService::Resolve() and it seems that only nsProxyAutoConfig can cause UI freeze due to DNS. Can anybody who can reproduce this bug look at his proxy setting and also look into PAC file to be sure that it isn't dupe of #235853?

also make sure that you arent using any extensions when reproducing this bug, as if this bug isnt a dupe from bug #235853, its probably some extension bug... try to reproduce the bug in a totally new profile

I've tried it with new profile, but I can't reproduce it. Neither with STR from https://bugzilla.mozilla.org/show_bug.cgi?id=306922#c0 nor with any other configuration I tried...

my note was for anyone that still can see this bug, but thanks anyway Michal :)

Let's just dupe this unless proven otherwise. The other bug has a patch.