Closed Bug 33952 Opened 24 years ago Closed 24 years ago

Clicking on links or buttons sometimes does nothing

Categories

(Core :: DOM: UI Events & Focus Handling, defect, P1)

Product:
Core
Component:
DOM: UI Events & Focus Handling
Platform:
x86
All
Type:
defect

Tracking

()

Status:
VERIFIED FIXED

People

(Reporter: rob, Assigned: ruslan)

References

(
URL
)

Details

(Keywords: regression, Whiteboard: [PDT+])

Attachments

(1 file)

nspr log of socket/http modules around the dns hang (at the end)
162.87 KB, application/octet-stream
Details 
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...
Status: UNCONFIRMED → NEW
Ever confirmed: true
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.
OS: Linux → All
*** 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
Keywords: dogfood, regression
*** 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.
Severity: major → blocker
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
Whiteboard: [PDT+]
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.
Assignee: joki → ruslan
Target Milestone: --- → M16
Status: NEW → ASSIGNED
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.
Target Milestone: M16 → M15
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.
Priority: P3 → P1
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
Status: ASSIGNED → RESOLVED
Closed: 24 years ago
Resolution: --- → FIXED
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
Status: RESOLVED → VERIFIED
 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.
Component: Event Handling → User events and focus handling
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: