Closed Bug 646189 Opened 10 years ago Closed 10 years ago

Firefox fails to connect to the network if the Windows machine is brought back from hibernation


(Core :: Networking, defect)

2.0 Branch
Windows 7
Not set





(Reporter: a_nut_in, Unassigned)


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.
Version: unspecified → 4.0 Branch
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
Firefox claims: server at not found

In the firefox log, I found records like 
0[930140]: nsHostResolver::ResolveHost []
0[930140]: DNS Thread Counters: total=1 any-live=0 idle=0 pending=1
3936[6198e40]: nsHostResolver::ResolveHost []
1812[6198f80]: nsHostResolver::ThreadFunc entering
1812[6198f80]: resolving ...
1812[6198f80]: lookup complete for ...

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 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 (?)
Component: General → Networking
Product: Firefox → Core
QA Contact: general → networking
Version: 4.0 Branch → 2.0 Branch
Ok, more precisely: in the first 25 seconds after a standby or hibernate, firefox does not find the hostname 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:
"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
Closed: 10 years ago
Resolution: --- → INVALID
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.
You need to log in before you can comment on or make changes to this bug.