From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux 2.2.14 i686; en-US; m14) BuildID: 2000033008 When clicking a link, a form button, or the Back button to go to another page, sometimes the page will start loading and suddenly stop. The status bar reads "Document: Done", though sometimes the status indicator keeps moving. The page redraws, but it is the same page I was on. If it happens on a button, the page doesn't even redraw. If I was opening the link in a new window, the window is empty. It keeps doing this until I reload the page. On Bugzilla itself, this seems to happen about 30% of the time. It did this to me on THIS page. The "Open Bugzilla Entry Form" button did nothing when I clicked on it. I had to reload and put all the information back in. Reproducible: Sometimes Steps to Reproduce: 1. Go to http://bugzilla.mozilla.org 2. Attempt to report a bug 3. You'll have to click enough links that this bug is bound to occur on one of them Actual Results: The page stops loading, the status bar says "Document: Done", and the page I'm on simply redraws. If I clicked a form button, the page doesn't even redraw. Expected Results: It should have gone to the destination of the link or the button.

dragging the mouse a little before releasing it usually works around this, if that helps anyone locate it...

Confirming! this is really painful. Bugzilla's query submit button often takes two clicks, buglist links often take two clicks.

I think it's *double-clicks* that are suddenly needed to activate links or buttons. Click once - wait - it says "page loaded" - url-field updates - no page loads. Wait a while, click again: same phenomena. But *doubleclick* the button or link and things (mostly) loads ok. Another side to this: If you click once, wait - then once more - nothing happens cept Moz saying "page loaded". BUT: If you then click (actually double-click) on the BACK-button - the page you initially wanted to go to will load :) Tested with nightly build 2000033008 and yesterdays for Linux.

changing OS to All. tested in win32 build from 3/30 (under NT and 98). I believe this started on the 27th or 28th.

*** Bug 34087 has been marked as a duplicate of this bug. ***

*** Bug 34139 has been marked as a duplicate of this bug. ***

Using 2000040109 on Linux 2.2. I'm seeing additional problems. You've noticed it takes two clicks for a url to popup, well I'm seeing as many as ten. For instance, type freshmeat.net into the url bar and I had to hit enter seven times for it to load. Note that my system *does* show tx/rx traffic, it just dies afterwards. Slashdot.org took five return hits, links on the mozillazine.org page often take as many in mouse clicks. Importantly, I am *not* seeing dragging the mouse and releasing as a fix, makes no difference for me.

Concurring with jg, using 2000040109 on Linux 2.3.99pre3. There are some links that I just cannot get to -- no matter how many clicks, or double-clicks, or drags, or whatever. I can positively say that double-clicking doesn't affect the problem, not only because I've experimented with [really slow|really fast] double-click rates, but because the problem appears when you're using the back/forward/reload buttons or typing an address and hitting enter. I've had to revert back to using Netscape 4.72 because this bug makes mozilla unusable -- when you cannot go forward, or backward, or load a new document, the browser is completely nonfunctional. I'm surprised that this isn't a dogfood issue : is anyone else affected as seriously as jg and I seem to be? asadotzler - I first noticed the bug in the March 24 nightly. This should be a blocker.

CC'ing travis on a suspicion that this problem is inside nsWebShell. By adding some printf's, I determined that we are passing the correct URL to load at least up through nsWebShell::DoLoadURL. However, the message that prints after loading is done: Document http://foo loaded successfully shows the OLD page instead of the NEW one.

I'm CCing hyatt as well. I've mentioned this to him in the past few weeks. I see this same type behaviour sometimes when clicking on menu items. Basically if I hold the mouse down longer it seems to work. Sounds very similar to this link clicking problem.

I don't see any improvement in the condition if I hold the mouse button down longer -- like the double clicking, I'm thinking these 'workarounds' are just the result of random chance and optimism. I'd concur, though, that I've seen the same behavior once in a while in the menus, and were it not for bryner's efforts one might be tempted to think it's the event handler's fault. But since we know that the events are being handled correctly, I don't think that these two bugs are related.

The part I mentioned about the line: Document http://foo loaded successfully might be a false lead. It seems that EVERY time you click on a link, whether this bug shows itself or not, the message that prints out there refers to the old URL. Could be a related bug though.

Double-clicking does seem to help for me. It appears that if you click again during the short time Mozilla spends trying to load the page, it loads. Sometimes I'm not fast enough and I have to triple- or quadruple-click. I agree that this should be raised to blocker. I don't plan to do much more testing until this bug is resolved - I can't tell if I'm seeing other bugs or just other facets of this one. Also, if I wanted to wear my finger out by clicking rapidly to get anything done, I'd play xbill. :)

*** Bug 34284 has been marked as a duplicate of this bug. ***

I don't know if this is related or not, but going into mail/news, I can create a news server but clicking on it in any number of ways does sod-all. I tried click, double-click, right-click. Nothing, nada, bugger-all. I then click on the Edit menu and mozilla 'cleanly' quits. using the same build/os as mentioned previously. The app is (almost) unusable for me with this bug.

adding dogfood and regression keywords

*** Bug 34333 has been marked as a duplicate of this bug. ***

Enough comments about it needing to be a blocker that I took my chances and raised it :-). This one has very nearly put a stop to my using Mozilla at all. I haven't seen the double-click be much different than just clicking again. Often waiting a second or two and clicking a second time will solve it here.

It's fixed!!! In the latest nightly for linux, clicking no longer 'does nothing'. Of course the new behavior (segfaulting) isn't much more desirable. Anyone know if this new behavior is related to this bug, or if I should report it as a new one? Every time(!!) I click anything (bookmark, link, menu item) mozilla segfaults. Doesn't this fail the smoke-tests? Isn't this what smoke-tests are for?

Today's build doesn't segfault for me unless I turn off the Sidebar - then I get the behavior you describe, it segfaults as soon as I click anything. I've reported this as a separate bug. Meanwhile, the links seem to be working a little better - they only take 1-2 clicks now - but it's still a problem.

I've seen this on Linux recently, and am currently seeing it on winNT build 2000040413. It something that requires patience to have happen, but isn't exclusive to bugzilla.

marking pdt+ per meeting

I have been able to **consistently** work around this bug by 'pounding' on my mouse button. When I say pounding, I mean to press the key as quickly as I can; if you try this, you will see that it is impossible to do this without pressing the button very hard -- it's kind of like that wack-a-mole game. ;-) This would also explain why some have reported success with double-clicking -- because a double click is two *rapid* clicks in succession. The timing seems to be very sensitive. I'm not much of a programmer, but my guess is that the handling of mouse events isn't being forgiving enough of human "slowness" in clicking the button. Again, I would like to stress that this 'pounding' works every time.

trevorcor, tell us about the build and platform you're using. I've tried nightly builds from before the Linux version completely ceased to function, and I havn't been able to get 'pounding' to work on any more than a purely random basis.

*** Bug 34670 has been marked as a duplicate of this bug. ***

*** Bug 34670 has been marked as a duplicate of this bug. ***

*** Bug 34670 has been marked as a duplicate of this bug. ***

I've been seeing this in every CVS pull (a few per day) I've built for several days now. Linux x86, glibc 2.1.2. It seems to be timing related -- the number of clicks needed to successfully follow a link isn't consistant at all, I just have to pound that thing rapidly. (Needless to say... it's very very annoying!) If it's any help, when loading a frameset a random combination of the frames therein will come up blank. I think it's connected. If it is, I hope that helps identifying the level at which things are failing! FYI when I click a link and nothing happens, mozilla prints: Document [your URL here] loaded successfully: Document: Done ([really quite small number] secs)

*** Bug 34670 has been marked as a duplicate of this bug. ***

*** Bug 34637 has been marked as a duplicate of this bug. ***

If I add this line to my prefs.js: user_pref("network.http.version", "1.0"); ... I do not see the problem. Come to think of it, the problem did seem to appear at about the time that HTTP/1.1 was enabled by default. So. --Adam

ruslan, I can confirm that turning off HTTP/1.1 makes this bug stop appearing. It may just be masking some other issue, but you may have some insights...

ruslan, I concur that turning off http/1.1 makes this bug not appear. I am therefore adding you to the CC since you checked in all the http/1.1 stuff maybe you have some ideas?

Setting back to http version 1.0 worked for me, too, and the problem did start happening when the 1.1 changes were rolled in. However, I seem to be losing all network connectivity after a few minutes of browsing (through a proxy) with this workaround in place, so this keeps my vote. I get stuck on "Resolving host <my proxy host name here>" and I have to restart to get any network connectivity.

Another thing which might be related here is the DNS Cancel branch landing that took place on 3/27. I can't reproduce this problem in the 3/27 nightly build, but can in 3/28, so I suspect something during that day.

Is the a site where it can be consistently reproduced?

I can confirm the "getting stuck at 'Resolving host'" behavior. I had that happen a lot. I haven't seen it as much recently, though I'm not absolutely sure that it's gone--both problems seemed to show up at around the same time. I'm running the WinNT version.

I've seen it getting stuck in DNS once and it was before 1.1 was turned on by default.

cc'ing gordon as well, to see if he thinks dns or the dns cancel branch landing could be related to this.

I can't reproduce the link problem on Windows so far at all. Is it Linux where it's happening?

It was happening in Linux for me (but not after turning HTTP/1.1 off).

I've seen this problem on Windows (W2K) and Solaris. I've seen it happen with Bugzilla, as have others. In my own experience, http://www.theregister.co.uk/ produces the worst behavior. I can't usually get more than two clicks through.

I've been able to repeat this behavior 3 times in a row with the following click sequence (today's build, Win98). Starting from www.mozilla.org (the browser start page): 1) click the "NSS" link near the top. 2) Click "Developer docs" in the page's sidebar 3) Click Roadmap in the page's sidebar 4) Click "Developer docs" again 5) Try to click the "Building Mozilla" link on that page.

Hmm. My build's just finished. I tried to reproduce it all the suggested ways - it I couldn't. Is it some kind of timing problem possibly?

I've a theory based on bryner's log - so let me work on it for now.

Ok. I've a fix for the link-click problem. It was happening the following rare conditions: (1) the transport was a kept-alive (2) the next request was sent to the server successfully (3) the server has managed to close the connection before receiving the actual request The fix would detect such condition while processing OnStopRequest () and attempting to restart the request using a brand-new transport. Nevertheless. On some sites I'm seeing strange behavior (whihc I've seen before, but now it's perceptionally happens often), where the request never completes. Further investigation shows that the DNS service never sends anything besides OnStartLookup (). It may be completely unrelated problem, but I'm afraid to check in anything until it's investigated. Gordon? My changes are on linkclickfix_tmp_branch; The site in question is www.oracle.com

In Build 2000-04-06-16 Win-32-Talkback I'm seeing this behavior with almost every mouse-click. ie. the first click on a link or a button almost never is processed properly.

Submitted bug 35150. This error is NOT rare.. happens all the time. TCP receive and send-queues are kept alive forever. I only went to some 5 sites but all those sites remained listed as active tcp queues, regardless of where i went later. Didn't vanish till i quit mozilla. Was on a simple html page (no frames) when i quit, and moz then released an amazing number of webshells (between 20 and 30) and of course leaked a few as well.

Adding myself to cc list as well...this is VERY annoying for me as well.

*** Bug 35115 has been marked as a duplicate of this bug. ***

I've a fix, but I'm not checking it in until I'm 100% sure that it's not causing DNS hang ups which I'm seeing on www.oracle.com

I really hope we can get a good patch for this in for M15 and not M16 like this bug is marked. I don't want to introduce DNS hang ups that ruslan mentioned, but speaking from the stand point of someone that does QA and bugzilla work this could be a problem. As we all know a large number of people get the Milestone builds that don't necessarily get the nightly builds and that will increase with the press over NS6 beta 1.

*** Bug 35190 has been marked as a duplicate of this bug. ***

*** Bug 34139 has been marked as a duplicate of this bug. ***

*** Bug 34139 has been marked as a duplicate of this bug. ***

*** Bug 34307 has been marked as a duplicate of this bug. ***

*** Bug 35266 has been marked as a duplicate of this bug. ***

Just for reference, with ruslan's fix applied, I am not seeing a DNS hang on www.oracle.com (current build, Linux. both opt and debug).

Hmm. May be it's just my win2k then.

*** Bug 34284 has been marked as a duplicate of this bug. ***

*** Bug 34950 has been marked as a duplicate of this bug. ***

*** Bug 34284 has been marked as a duplicate of this bug. ***

*** Bug 34950 has been marked as a duplicate of this bug. ***

I have had no DNS problems on the linkfix branch either (also linux, this is debian GNU/linux powerpc (potato)). About a day of heavy usage, it has performed admirably.

Well. I can check it in of course. But with simple workaround by disabling keep-alive in M15 in prefs it works just fine anyway. I don't know. The changes are somwhat big. I'd rather put it into M16. And I'm definitely seeing some weirdness with DNS, though I'm now thinking that it's unrelated.

ruslan, if you don't feel comfortable with the patch to prevent dup bugs can we turn of http 1.1? I hate to say that, but it might be better from a QA standpoint.

I agree with asj@ipa.net. We either need to disable by default in the M15 release or risk the fix. This bug has like 20 duplicates and would have had dozens more if not for the work of volunteer QA staff letting potential reporters know that it was already reported. This bug seems a little big to release note. my two cents, Asa

I'd vote to release note it. This is the first time we've 1.1 On and we want to collect as much feedback as possible to be able to flush out as many bugs as possible. http/1.1 can have multiple implications on cache for example/etc. You can always turn it off (network.http.version="1.0")

I think it may be difficult to spot other bugs in the HTTP/1.1 implementation if this one keeps popping up. If you don't want to check in the patch, I'd vote for turning off HTTP/1.1 by default, but release noting the fact that it is there, with a caveat about this bug.

(Adding myself to cc list) This bug sucks way too much to have it happening in a milestone release. It will be the first and only thing that 95% of non-loyal testers will complain about. By that time they will have deleted it already.

I hate to "me too" but I'm in regular contact with a number of folks in my Linux User Group who used to get dailies every day. Nearly every one of them asked "what the hell happened" when this bug popped up, and stopped downloading dailies. Since I pay attention to these things, they asked me to let them know when it is fixed. They'll start tracking it again then. To have a milestone go out the door with this is going to look very, very bad- if even my hardcore Linux friends (who are used to bugginess/beta-ness) don't have the patience for this bug, very few people will.

I run W2K at home... is there a bugfixed version I could try to see if I get the same DNS hangups? I tend to agree this is a show stopper. If the bug is left in, then you can either: a) leave HTTP/1.1 enabled, and not get useful feedback on other things from people who will decide the milestone is horribly broken and delete it; or b) disable HTTP/1.1 and not get useful feedback on that. I hate to say it, but 99% of what a person is going to do with a browser is click on links, and I don't think the choices of disabling HTTP/1.1 or bouncing like a wild monkey on the mouse button are particularly appealing.

If you could make a fixed binary available for linux, too, this would allow more people to test it.

I agree that this is a critical bug. Given that it can be resolved by rolling the pref to disable this new feature (great as it may be, it is incomplete enough to generate this critical dogfood bug). I've set the TFV back to M15 to get that critical pref change landed. It is never reasonable to half-land a feature, leaving the build horked. I know this was not intentional at all, and was great progress... but the current situation is not acceptable.

The problem here is the windows version isn't so bad - it's not reliably occuring for me, and I only have to click twice. The bad part is Linux where the browser is unusable - I downloaded yesterday's build linux 2000041008 and I had to click on links 10+ times. I just shut it down.

Mac is also not usable as-is, too.

So you want me to merely change the default pref or roll in the fix for M15?

ruslan- I noticed you made some additional checkins to linkclickfix_tmp_branch last night. Did that help the DNS hangs you were seeing? Does it make the patch safer to go in for M15?

No. I fixed some other things there, like a memory leak and some other bugs I've been working on. I'm fairly convinced at this point that DNS hang is a problem of it's own is likely not related to my patch. DNS sometimes goes into a state on Windows (nobody has reported this on any other platform), when it fires OnStartLookup and no other notifications - so you keep spinning; it looks like some sort of concurrency problem. I don't know how important M15 is as a milestone. I can turn http 1.1 off or I can check in the real fix. Somebody just have to decide this.

Adding myself to CC, first noticed in a the nightly build JUST after Netscape 6 came out, but apparently that's not the case.

Intruding again.. maybe i misunderstand this bug but could this be a cookie/network problem? In bug 35150 all URL's in the walkthrough send cookies. Many. And i have to click up to 15 times or more to get anywhere on them. Bug 35443 ("Page loading often fails to occur, causing the previous page to be duplicated") also refers to problems with link clicking and back/forward failing to happen or giving unexpected results. Bug 35443 is now assigned cookie-bug. Bugzilla was the first site mentioned in this bug here, and it also send/read cookies. Also note that storing settings for cookies is broken on linux, at least. Filed bug 35510 on that.

I agree - since I noted in bug 35443 that HTTP/1.1 seems to be a cause (doesn't happen when it's turned off), this makes me highly suspicious...

sorry: marked bug 35510 invalid. Storing cookie-prefs OK in nightly w/fresh profile.

cc'ing leaf so we don't ship with this one. And upping the priority.

Ruslan, In response to you question about someone making the call: You should turn off HTTP 1.1 in the M15 branch. Regression in link traversal it too much bustage for a checkpoint. Assuming you can land the real fixed on the trunk, that is fine. IF you can't land the real fix, you should turn off HTTP 1.1 on the trunk until the fix is ready. Again, thanks for some excellent work getting this feature in... but we really can't afford to land features with such significiant regressions (...or when we spot 'em, we have to pref-out, or roll-back, or solve the regression ASAP).

Allright. I just landed the fix into the tip. The DNS bug was unrelated. We discovered that DNS service on Windows wasn't releasing message IDs, thus causing the browser to lock up after 128 lookups and was around for a while (I'm surprised noone has noticed it before). Anyway. We can land everythin into M15 or just turn http 1.1 off there and land the DNS fix (cuz I think it's pretty bad).

Fixed on the tip. A small patch is sent to leaf (turns off http 1.1 and fixes the DNS) and will be applied to M15

I'm still seeing this. Current example: destroy a few windows, hit a link in remaining one. CPU -> 100%, window follows link but becomes only semi-responsive to scroll-bar events: a focus-transfer to and from another mozilla window is required to cause appropriate redisplay. Gtop shows 1 mozilla-bin thread @ 100%CPU, three idle. May be some improvement in click behavior, requiring less flailing. Current CVS build, linux k6 etc.

Does it have anything to do with the original bug?

I think that jb@as220.org's bug is one of the several symptoms of bug(s) with having multiple browser windows, and unrelated to the original problem. I've certainly seen it in situations where all the windows loaded their URLs successfully on single-clicks. jb: if you can consistently reproduce the problem, please please file a bug. Working with multiple browser windows is really painful right now, and I'd love to see consistent ways of reproducing the problem found so that people can zero in on the actual bugs.

I just did a fresh CVS build and am still seeing the problem, but there is substantial improvement. Example: Document http://cnnfn.com/ loaded successfully Document: Done (12.156 secs) Document http://oss.sgi.com/projects/xfs/ loaded successfully Document: Done (18.147 secs) [I hit back button] Going Back [nothing happens. cnnfn.com still displayed]. This is not reproducible. With further testing, I am getting only single-click success with the back and forward buttons. I also can't get any action by single-clicking in the bookmark sidebar. Only double or more clicks work. I am having good single-click success with the toolbar bookmarks. The bookmark sidebar is still reliably bad, requiring double-or-more clicks to do anything. I don't know if that is considered a separate bug. As an aside, mozilla went straight to 100% CPU on startup.

I was unable to recreate this bug on any of these builds. Marking verified. verified on WinNT 2000-04-20-09 verified on Win98 2000-04-20-09 verified on Linux 2000-04-24-09 verified on MacPC 2000-04-24-16

I confirm this fix on a Bleeding-Edge k6 linux system. I did a build several days ago, and saw no sign of it. The CPU-burning-thread bug and the massive-amounts-of-CPU-for-bookmark-managing bug also seemed to be gone. I'm doing an update and build, and will advise should this bug recur. Excellent debugging progress; M15 must be a good one.