User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:2.0) Gecko/20100101 Firefox/4.0 Build Identifier: Mozilla/5.0 (Windows NT 6.1; rv:2.0) Gecko/20100101 Firefox/4.0 When working on Windows 7, if the system is left unused and Windows 7 goes into hibernation with Firefox running, on resuming from Hibernation, if we try browsing on Firefox, the same either takes ages to connect or does not connect at all. Even if we open a new tab and open a new website, the page does not connect. Closing Firefox and opening Firefox seems to fix the issue. Reproducible: Always Steps to Reproduce: 1. Open firefox and keep it running 2. Keep the system unused and allow Windows 7 to hibernate the system 3. Power on the system back by pressing the power button and log back into the Desktop. Firefox should still be running. Try opening a webpage in firefox and IE IE would connect back to pages immediately whereas firefox would either not connect at all or take ages to connect Restarting firefox seems to fix the issue

Wfm with Firefox4 and Seamonkey trunk on win32 and suspend to disk.

Cannot repro the issue with the Aurora build

Same here with FF 4.0.1 and win XP. After standby or hibernate, FF tells me that it cannot find the server. After waiting 30s or so, everything works fine. Analysis with "live http headers" and wireshark showed that in these cases FF does not send a http request. I.e. it is not a windows or stack problem.

I made the following test: I used "set NSPR_LOG_MODULES=nsHostResolver:5" to activate FF logging. I started wireshark capturing. Then I put the machine into standby and activate it again. In firefox, I try to get the url www.test.com Firefox claims: server at www.test.com not found In the firefox log, I found records like 0[930140]: nsHostResolver::ResolveHost [host=www.test.com] 0[930140]: DNS Thread Counters: total=1 any-live=0 idle=0 pending=1 3936[6198e40]: nsHostResolver::ResolveHost [host=www.test.com] 1812[6198f80]: nsHostResolver::ThreadFunc entering 1812[6198f80]: resolving www.test.com ... 1812[6198f80]: lookup complete for www.test.com ... But in wireshark, there is no DNS request!

It seems the error code from nsLookup is -5987

>FF tells me that it cannot find the server .. >Analysis with "live http headers" and wireshark showed that in these cases FF >does not send a http request. I.e. it is not a windows or stack problem. The error message tells you that this is a "DNS entry not found" error. There will be of course no http request in such a case. >Firefox claims: server at www.test.com not found >But in wireshark, there is no DNS request! There doesn't have to be a DNS request over the net. Firefox uses the windows API getbyhostname() to do DNS requests and windows caches DNS answers. "ipconfig /flushdns" clears the window dns cache btw. There is AFAIK also a DNS cache in Gecko but it doesn't cache negative DNS answers (?)

Ok, more precisely: in the first 25 seconds after a standby or hibernate, firefox does not find the hostname www.example.com. Afterwards, it finds it and displays the page. So it cannot resolve host names in the first 25s, while nslookup will work. Requesting a web page by IP address works fine.

Is ping hostname working in the first 25s ?

First it did not want to test it and write you that nslookup is working. But then I tested and you are right: ping ist not working either while nslookup is working. Ping could not resolve the host name. This is strange.

The DNS problem after standby/hibernate is not a FF matter, its a windows problem: http://forums.vr-zone.com/troubleshooting-zone-technical-enquiries/181329-dns-problem-after-hibernate-wakeup.html

"net stop dnscache" seems to fix this

nslookup does the DNS lookup itself (AFAIK) and doesn't use the OS API as most applications are doing. That's the reason why I suggested ping. I will mark this invalid because this is a bug in the OS

This thing came back now with 36.0.1 After hibernation, the browser does not connect any more and the firefox process cannot be killed.

"cannot be killed" is different. Try https://developer.mozilla.org/en-US/docs/How_to_Report_a_Hung_Firefox ? See also bug 1125686 comment 7.