From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.2+) Gecko/20010731 BuildID: 2001073106 All too often, I've found my Mozilla windows to be less than responsive, and when this happens, it's often quicker to start Netscape 4 to fetch a page than to wait for Mozilla to finish with whatever it's busy doing. The throbbers spin, but all windows just seem to pause in fetching any data from the network, even with sites which may be working fine from Netscape 4 at the same time. Usually, the delay is only seconds, but it's not uncommon to take minutes. Every once in a while, it just hangs entirely. Today is a Thursday. On Tuesday, I was browsing and it hung entirely. To see if it would eventually finish, I left several pages trying to load, with the throbbers spinning. Literally TWO DAYS later, they were still spinning, having made no progress at all. This includes a window that was launched defaulting to my home page of www.google.com, which is generally a responsive site. Although Mozilla was responding to UI input, menus worked and I could even create new browser windows, it was completely useless. There were no dialog windows, even after days of trying to fetch a URL from the network -- this didn't appear to be related to TCP/IP errors at all. I doubt the TCP connections were even being attempted, though I didn't trace anything to find out. This problem has been getting more and more annoying over the last few months (and I don't remember it happening early this year), and it's getting to the annoyance level that I'm seriously considering going back to Netscape 4 as my primary browser, after using Mozilla as my primary browser for about 10 months now. This is a serious problem. My gut instinct tells me that this might be related to DNS lookups, but I'm not sure whether or not that's actually the case. Currently, are DNS lookups fully asynchronous, or are they serialized? Could that part of the code be getting locked out by a semaphore or anything like that? (Maybe it's something else entirely?)

Please try a recent build. The one you are reporting this bug with seems to be 7 weeks old, which is normally too old to be of value bug-wise. See http://www.mozilla.org/quality/bug-writing-guidelines.html Quote: "Next, be sure that you've reproduced your bug using a build released within the past three days." FYI: The spinning icon doesn't necessarily indicate network activity - the socket itself times out after a few minutes. When a bug like the one you describe occures, you can let mozilla spin on for a year for that matter: it won't retry to open a socket/connection unless explicityly told so again. I haven't seen such "spinning" bugs for quite a while now - WFM with a current CVS build, linux.

The only way to reproduce it with a recent build is to update Mozilla daily, since I can't reproduce it on demand, and it's erratic. That's a nuisance when I often leave Mozilla windows open for days at a time. I just downloaded today's build, but I don't know when I'll see it happen again. Certainly, I'll add a comment here if I see it again. Usually it's not as blatent as this last occurrence -- more commonly, it's slow but it eventually recovers -- long after Netscape 4 could fetch and render the page... (And in such situations, I often do launch Netscape 4 to fetch the page that's dragging...)

Okay, I've just reproduced the problem with 2001092106, although not to the extremes as the original report. Is 6 days also too old? I was at the following page: http://www.uclick.com/client/cap/gm/2001/09/10/index.html It was taking a very long time to load this ad image at the bottom of the page (I think; maybe this is different, if it's dynamically selected): http://ads1.intelliads.com/html-bin/adselect100.asp?obnum=609600&site=85390&cbvar=6286 I wanted to look through the cartoons from other days, and selected September 11 from the drop-down and hit the "click" button to load it. The browser started spinning, but nothing else was happening. Meanwhile, I launched a new browser window and it was stuck (spinning) trying to load my homepage, www.google.com. After a number of seconds, I launched a Netscape 4 window and went to the same page that was first stuck in Mozilla. It loaded fine in a couple seconds. Then I selected September 11 the same way and clicked on the button. That loaded in a couple seconds also. I then loaded and viewed September 12, September 13, September 14, September 18 and September 19 in sequence -- and then Mozilla FINALLY loaded September 11, and the other windows unfroze and Google loaded. This is exactly the same problem I described last week. This is the bug that's starting to make me regret making Mozilla my primary browser almost a year ago. What will it take to get this bug investigated? (If someone wants to give me any pointers as to where in the million lines of code to look, I'll look into it myself -- where is the DNS lookup code?)

Deven: Are you using a proxy or do you have direct connection to Internet? See the duplicate bug. *** This bug has been marked as a duplicate of 95499 ***

This bug is NOT fixed, but it does look like a duplicate of bug 95499, so I'll try to move the discussion there if possible. If that bug doesn't get reopened, I'll have to reopen this one. I've reproduced this on build 2001100321, which was the most recent nightly build as of an hour ago. I described in bug 95499 how I reproduced it. I am not using a proxy, only a direct Internet connection.

I'm reopening this bug, because bug 95499 was marked as FIXED. Duplicate or not, this bug isn't resolved. Here's my relevant comments from the other bug report, duplicated here now that I'm reopening the bug. These were written yesterday: [...] I just reproduced this with the latest nightly, 2001100321. I have a test CGI that normally returns very consistently in about 0.25 seconds. I went to the test page http://www.uclick.com/client/cap/gm/2001/09/10/index.html which was mentioned under bug 100826, and kept selecting different days (and clicking on the "click" button) until one got stuck. As soon as that happened, my other window talking to the test CGI froze also. It took 74 seconds for the test window to unfreeze itself, and then the test CGI also unfroze. Only at the very END of that 74 seconds did it open the connection to fetch the test CGI -- I was running a tcpdump and saw the SYN packets go out only at the very end. The test CGI was at http://escher.ties.org/cgi-bin/date for testing, but that's close to me on the network (it's my home machine), and may not work for others to test. I've already uploaded that test CGI under bug 40867 on 7/20/01, if anyone wants to use it locally for testing. It returns a date, tries to suppress caching, and has a GET link and a POST button to retrigger the CGI. Is there some sort of maximum connection limit causing this? I am NOT using a proxy, but it seems to refuse to open new connections when (enough?) old ones are hung due to network problems at other sites...

I sometimes see this when I go to Slashdot. The browser resolves, and then transfers data till the progress meter is halfway. Then all network activity dies and I never go to the page. This means that I often have to view slashdot in NS4. It is not 100% reproducable, but it appears to me that mozilla is ignoring some packet and is just waiting and waiting for it to come. I've never had other windows of mozilla stop responding networkly though, so this might be a seperate bug. Does anyone have a TCP log of their connections that they could post to this bug? It would make confirming that much easier.

I see this as well - Linux RH 7.2, on a wide variety of builds over the past few months. It occasionally happens in Mail/News also. It's basically as if Necko just ignores everything the browser tells it and anything coming in over the network. Type in a new URL and press enter and nothing happens at all. I normally restart Mozilla to fix it - but it is annoying. Gerv

found similar problem at www.ual.com. Click on "advanced search" link upper left of page, then on next page click on "log in as guest" link. You get a "Please wait while we retrieve the information" message and a bouncing ball that never stops. sounds like same bug. Using Mozilla 0.9.6, build 2001112009, same problem with Netscape 6.2, works with IE 6 Bob McConnell

the www.ual.com bug is a problem on the server side w/ not sniffing mozilla properly. cc'ing jst, who own(s/ed) that bug.

Original reporter, do you see this bug in recent nightlies? If not -> WFM Linux 2002010621

I've noticed this bug since at least 0.9.4 (when I started seriously using mozilla). A web site that frequently causes this problem for me is espn.go.com. Usually I will load up that page, click on a link to read a story, then try to hit the back button and mozilla stops downloading any pages for a while. I'm currently running 0.9.7 (Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:0.9.7) Gecko/20011227) on FreeBSD 4.4.

Reporter: is this stil a problem

chris: i played around with stuff on espn's website using the 2002011108 linux build and didn't encounter any problems. can you describe how you connect to the internet? for example, are you connecting via a web proxy? and if so, do you know what kind of proxy it is? thx!

This continues to be a problem, even with current builds. I use Mozilla at work also, but I never have this problem there. The only obvious difference between the two machines is that the problem one is running Win 98 and my work machine is Win 95.

Mozilla/5.0 (X11; U; Linux alpha; en-US; rv:0.9.8) Gecko/20020205 I think I am seeing this bug, although the it does seem a bit different (except for Gerv, comment #8). I am completely unable to load any URL. One time, it transferred all the data and then waiting 30 seconds, and then displayed the page. Other than that one time, the throbber just keeps going forever.

tcpdump log connecting to http://www.mozilla.org/start. I used sniffit to verify that all of the html and css pages were successfully transferred. Also, Netscape, lynx and a new instance of Mozilla are successful in loading the URL.

I should add that none of the page is displayed. Shouldn't Mozilla display the page as it receives it? Also, general browser performance while the bug is active is very slow, although it only uses negligible CPU.

Reporter: Can you try to reproduce this bug with the latest build?

I would be very interested in learning if this is occurring because a DNS lookuup fails, and blocks further DNS requests in mozilla. Or, it could be some general blockage of everything. The way to test is to try to connect to an IP address after you encounter the initial hangups.

Currently, I cannot verify whether or not this problem remains. My networking configuration changed in December, and I am now behind a firewall, and all my web browsing is through a SOCKS proxy that tunnels through SSH to my home machine where the SOCKS server is running. This works, but it's slower than a direct connection, and I get many delays and hangs due to the proxy that make it hard to watch for this problem. However, there's a possibility that I may get an opportunity to move my machine outside the firewall. If so, maybe I'll be able to determine whether or not this bug has been quashed. For now, it probably needs to remain undetermined...

moving neeti's futured bugs for triaging.

I'm assuming this bug is fixed. I haven't seen this behavior in well over a year.

thanks for the response ! (but no patch = not fixed)

-> wfm