Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5b) Gecko/20030913 Firebird/0.6.1+ Steps to reproduce: 1. Try to load http://127.0.0.1/ from the address bar. Expected: "Connection Failure Error" error page. Result: Throbber keeps spinning, status bar says "Connecting to 127.0.0.1...", error page does not load. Why this is major: This bug also affects SCRIPT objects. Many users "block" ads by setting ad hosts to 127.0.0.1 in their hosts sites. For these users, sites with <script src="http://ad.doubleclick.net/showAdHere.js"></script> don't display completely because the script load stalls instead of failing quickly. (Reported at http://forums.mozillazine.org/viewtopic.php?t=24689#192636 against http://www.winfuture.de/ , http://www.zdnet.de/ , http://www.kicker.de .) This is a regression in 09/12 builds of Seamonkey and Firebird. 09/11 builds of both worked correctly.
Sounds like the retry logic for refused connections is hosed.
It would appear this is probably caused by the code for bug 205726.
This appears to happen on both connection timeout errors as well as connection refused. In either case it appears to just try forever.
don't use flasg if you don't know what they mean
WFM Firebird 20030912: 1. Open firebird 2. Type 127.0.0.1 in URL bar and press enter 3. "The connection was refused when attempting to contact 127.0.0.1" Am I missing something? I am sure this build has the DNS rewrite code because IPv6 works.
OK. Firstly this is not just a 127.0.0.1 issue. THe same problem will occur sith a perfectly legit URL if the server is not accepting conections for some reason. Secondly, I have done some testing on this with a sniffer on the network. Here is what I found. The conenction retry logic actyually does appear to be working as it should. If there is only one address it tries to connect 3 times. If there is more than one address it tries 3 times for each address. So It is not (as I had feared) attempting to connect continuously. This would have been a very bad things as it would ahve set off alarms on most Intrusion Detection Systems. So this is still a serious issue, but at least we won't have users getting calls from their ISPs asking them not to run Mozilla Firebird. So it appears that it is doing the corret retries, it is just that when the retries get used up it is not behaving correctly.
Re comment #5. Are you using Windows? This could be a windows only issue. There is code under a windows ifdef that tries to make dialup connections if it can't connect. The hang could be occuring withing this section of code. My personal opinion is that this code should be removed because recent versions of Windows will have alrady tried a dialup connection before getting to this point under a user condifugrable network option.
Yes, I am using Windows XP. But I don't use dialup connections because I'm behind a router.
Summary: URLs with no server stall instead of giving Connection Failure Error (sites with scripts from ad hosts don't load completely if ad hosts are set to 127.0.0.1) → Failed connections stall instead of giving Connection Failure Error (sites with scripts from ad hosts don't load completely if ad hosts are set to 127.0.0.1)
Well tht makes liitle or no sense, I am running Windows XP as well and I have this problem even if I am connected via dial-up. Do you have any dial-up connections installed at all? If not perhaps that is the difference?
This bug has the following effects: * If a site is down or doesn't resolve, the browser appears to be waiting for the site when it could have given a useful error message. * Typing "scrippscol.edu" (without www) into the address bar no longer gets you to http://www.scrippscol.edu/ . * If you use a hosts file to block ads, many sites don't load completely. (You can't see all the non-ad content on those sites.)
Re comment #4. I was trying to set this bug a blocker to the next release, which as near as I could tell would be 1.6a. 1. If setting the blocking 1.6a is not the correct way to do this then what is? 2. If you think the next release should go out with a bug a serious as this in it you are brain-damaged. 3. If it is too early to set bugs as blocking 1.6a, then the choice should not exist. 4. If only certian people should be marking bugs as blocking and I am not one of them then my bugzilla account should not have the priviledge to set this flag. Just my opionion, I could be wrong.
> 1. If setting the blocking 1.6a is not the correct way to do this then what is? The correct thing is to nominate it as a blocker by setting the blocking1.6a flag to "?". > 2. If you think the next release should go out with a bug a serious as this in it you are brain-damaged. This isn't that serious - the browser is still quite usable. Alpha releases usually go out with bugs. However, I agree that this should be fixed, and I'm setting the flag to "?". > 4. If only certian people should be marking bugs as blocking and I am not one of them then my bugzilla account should not have the priviledge to set this flag. That is true and there is a bug open for fixing that. However, it is hoped that most people won't change things without understanding them. If they do, then people can tell them how it is supposed to work and change it back (as in comment 4).
re comment #12. Thank you. Very good explanation. SO I was supposed to have set it to a ? and not a +. I wihsh the person who turned it off would have told me that instead of basically being of no help at all.
Re comment #12: > This isn't that serious - the browser is still quite usable. Alpha releases > usually go out with bugs. However, I agree that this should be fixed, and I'm > setting the flag to "?". At the time I was orginally trying to set this a s a blocker the bug was thought to be more serious. Up until the time I put a sniffer on the network to see what was actually hapening it was though that the browser was retrying connections indefinitely on a connection refused condition. I agree the browser is quite usable and works just fine unless there is some kind of networking issue or webserver issue and things are down in which case it kind of just hangs. Another problem is that this bug can mask other issues becuase if Firebird now hangs for any reason whatsoever, we couls easily be fooled into thinking it is just this bug. Also, since I have been using firebird nightlies since mid July, this is the only bug that given if the only 2 browsers that were availbel to me were IE and a Firebird browser with this bug, I would use IE as my default browser. That is the major reason I would not suggest any release (even alpha) go out with this bug.
Oh dear. This issue has just been made worse by a combination of action by Verisign and some ISPs. Verisign has launched a new "service" they call Site selector. To implement this they have abused their posion of managing the top level net and com domains and have added wildcard A records to both pointing to a server that they control so that they can present a hey you can buy this domain from us, or maybe you typed it wrong and wanted to go to xyz.org not xyz.com, etc. site complete with ads etc. See: http://www.wired.com/news/technology/0,1282,60473,00.html for some background on this. Well, now in addition to the DNS block efforts, some ISPs are blocking port 80 access to the IP address 220.127.116.11 (which is the address the wildcard A record points to). So now if you misstype a URL which should end up just getting a no such host error becuase it is not in DNS, DNS returns the 18.104.22.168 address which your ISP is likely to be blocking so you end up running into this Firebird hang issue even more often than you would have normally. ... sigh :-(
William A. Gianopoulos wrote: > Well, now in addition to the DNS block efforts, some ISPs are blocking port 80 > access to the IP address 22.214.171.124 (which is the address the wildcard A > record points to). According to the Wired article, the block affects the BIND software that is used by approximately 80% of the Internet's domain servers. It seems that "Some ISP's" is an understatement. :(
i can reproduce this on using the 20030916 trunk seamonkey build under linux (rh9)
Status: NEW → ASSIGNED
OS: Windows XP → All
Target Milestone: --- → mozilla1.6alpha
Re: commnet #17. So much for the story that this is a windows only bug.
*** Bug 219703 has been marked as a duplicate of this bug. ***
This is listed as a browser bug. Should it not be an NSPR bug?
Hmmm. Looking more closely at at he components decription, it should probably be a netlib bug but that does not appear to be a choice. My point is that this is listed as a browser bug, but my guess is that it effects mail/news as well, but you would never guess that or find it searching in Bugzilla. What is the proper thing to put for the product designation on a bug in the netwokring code that effects all components?
*** Bug 219945 has been marked as a duplicate of this bug. ***
*** Bug 220206 has been marked as a duplicate of this bug. ***
*** Bug 220323 has been marked as a duplicate of this bug. ***
From http://forums.mozillazine.org/viewtopic.php?p=207315 : Kazaa Lite creates an ad-blocking hosts file. Not all Kazaa Lite users know that they have a hosts file.
In answer to comment #26 I had Kazaa Lite, but have removed it from my system around a month ago. Also removed last traces of it with Adaware and Spybot. I can assure that is not why I am stuck on Mozilla 20030904.
email@example.com: you're also using a bug from before this regression was introduced :)
I am using Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.6a) Gecko/20030927 at this moment. When my HOSTS file contains advertisement blocking links, Mozilla Seamonkey still refuses to load sites fully (stuck at 99% loading bar). I now cleared my HOSTS file of the ad-blockers, logged off and back on and am now able to go to those pages I wasn't able to get to. For now I'll live with the popup blocker and blocking images.
*** Bug 220503 has been marked as a duplicate of this bug. ***
firstname.lastname@example.org: You have to request flags by setting "?". Only Asa and a few other people may set "+". Also, this bug doesn't affect the 1.5 branch :)
*** Bug 220971 has been marked as a duplicate of this bug. ***
*** Bug 220440 has been marked as a duplicate of this bug. ***
*** Bug 221375 has been marked as a duplicate of this bug. ***
dup *** This bug has been marked as a duplicate of 219376 ***
Status: ASSIGNED → RESOLVED
Last Resolved: 16 years ago
Resolution: --- → DUPLICATE
all the dupes and votes are on this earlier bug, but there's a patch on that one, so I guess it has to be duped this way... verified
Status: RESOLVED → VERIFIED
No longer depends on: 219376
*** Bug 222490 has been marked as a duplicate of this bug. ***
REOEPEN: Was this problem fixed by fixing bug 219376? That doesn't make this problem a dupe, in an imperfect world of patches fixing more than one bug, it should be recorded as a depends. I'm also removing the blocks on 219150. This bug would have blocked all Domain Guessing, but that bug was just a Domain Guessing RFE.
Status: VERIFIED → REOPENED
Resolution: DUPLICATE → ---
(correction: removing depends on bug 219390...) adding depends for bug 219464 (problems caused by site minder)
i don't think this has anything to do with the Verisign NXDOMAIN crap! this was a regression from the DNS resolver rewrite. it is just another symptom of the same underlying problem that was fixed by my patch for bug 219376. i think bienvenu was correct in marking this a duplicate of that bug. though the descriptions might sound different, these two bugs are very much one and the same. *** This bug has been marked as a duplicate of 219376 ***
Status: REOPENED → RESOLVED
Last Resolved: 16 years ago → 15 years ago
No longer depends on: 219464
Resolution: --- → DUPLICATE
You need to log in before you can comment on or make changes to this bug.