From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux 2.4.0 i686; en-US; 0.9) Gecko/20010301 BuildID: 2001030105 When I'm offline and I try to get a page, Mozilla send a DNS request. If I go online while Mozilla is still trying to resolve the address of the page, and Mozilla finally gets it, it shows a popup "failed to connect to server". (By "offline" and "online", I mean I'm connected to my ISP or not : it is not about mozilla function "Work offline") Reproducible: Sometimes Steps to Reproduce: Switch off your modem. Try to reach an internet page. Wait a moment, then start your connection with your ISP, reload the conf of your DNS server (I don't know if it is really necessary). Mozilla still tries to resolve the address of the page. The DNS server finally give the ip address for the requested page. Actual Results: We get a popup "Fail to connect to server". Expected Results: Mozilla should start to load the page and display it. I use a dial-up system at home, with a server running diald and a DNS server, which forward its requests to my ISP DNS server. When I'm connected to my ISP, a script runs a "/usr/sbin/ndc reload".
The exact error message written in the popup seems to be : "Connection timeout". And another problem related : the popup shown blocks all the other windows downloading, while it should only block the window it is related to.
Sorry about the last comment : i was wrong. The exact (you can trust me this time :)) ) is : "The operation timeout when attempting to contact www.slashdot.org" (www.slashdot.org is sure an example).
*** This bug has been marked as a duplicate of 28586 ***
> And another problem related : the popup shown blocks all the other windows > downloading, while it should only block the window it is related to. That's probably bug 74331, "modal alert dialog in any window blocks necko for all windows".
I'm reopening this, and I'm and my inclination is that it will end up invalid after some discussion about the actual order of events. Here's why: The other mentioned reports (bug 28586 and bug 74331) refer to how the error should be handled. What the reporter wants is to be able to start a transaction while physically disconnected from the network, and have it work if the network comes up before the application decides to error. In other words, they want NO error to occur. Although the overall requested behavior might be something reasonsable, I do not know if that is what is really going on. This also maybe something that turns out to be OS dependent. Much more analysis is needed her, and the burden of proof is high, (do we know the DNS server actually gave the IP address back to the browser and the error occurred anyhow?)
The problem here is that Mozilla seems to create the error popup only when it receives the ip address ... which is quite weird ! I believe that because I've "listened" the network using tcpdump, and the popup appears just when the DNS answer arrives. But maybe I'm wrong.
mass move, v2. qa to me.
Confirmed on Build 2001-06-09-20, Win2K OS should be changed to all. This can happen in either Mail/News or browser. After losing an internet connection (most occurring on dialup), Mozilla goes haywire and, at least for me, pops up several "Failed to connect to server." messages in succession. Marking my vote!
Dwayne: If this bug is going to go anywhere, I think it should stay Linux only. This bug is also very specific in the breakage and the requested fix. There are many other bugs that sound similar, that are probably what you really want. Can you look for a dupe or create a new bug with your steps for Windows? I've started to mark these bugs up with a "Conn:" string in the summary and am writing a new test case for this area (General connectivity).
Well, I've looked at a couple but this one seems to match it best. Let's hear from others out there what their take is. If it seems I may have a separate bug, I will be glad to file one. But I can't find anything in the original description that *doesn't* match what I see. At the same time, I noticed a similar (and perhaps separate bug) in MailNews. This may be what you think qualifies as a separate issue. To me, it seems that losing your internet connection (whether it be dial-up or otherwise) causes this error to happen, whatever specific cause it may be.
Dwayne, you should give yourself credit for correctly describing the generic problem first. This person is going online at a specific moment while running a local DNS nameserver. This is pretty complicated, and we have to solve the more basic connection problems first before we can really address this.
So therefore should I file a separate bug and make this bug dependent on it? I honestly think this is a side effect bug, not a dependent bug. (Difference being there's *no* way to fix the first bug without fixing the second as well -- a good thing of course) I will follow more knowledgeable superiors' directives. :)
Just a new bug. Problems in this area are scattered all over bugzilla, so keeping one problem per bug is ideal at this stage.
Created new bug 86192. This bug is now dependent on 86192. Added original reporter and Benc as CC for that bug for ease of reference.
Ooops! This is dependent on bug 86912. Sorry for the spam and typo.
Bugs targeted at mozilla1.0 without the mozilla1.0 keyword moved to mozilla1.0.1 (you can query for this string to delete spam or retrieve the list of bugs I've moved)
moving neeti's futured bugs for triaging.
RESOLVED/WFM: If this still happens, the reporter, or anyone else who is running in Linux w/ a local DNS server should REOPEN. Everyone else, new bug please. In general, there seem to be few complaints about mozilla recovering from a network disconnect;re-connect set of events. In this case, a local DNS server and Mozilla are cut off by the reconnect. When the connection is re-established, Mozilla then fails to connect to the IP address returned by the local server. The point of failure seems to be the the mozilla using the DNS server's response, and my guess is the local DNS server is giving some abnormal response that confuses mozilla. Since there is no DNS logging or analysis from other clients (nslookup, wget, etc), or a DNS isolated test (IP address only), this seems to be the most resonable interpretation.