290673 - hovering link sometimes triggers strange mouse and back button behavior

Status: RESOLVED FIXED

(Core :: DOM: Events, defect)

Description

[Benoît]

User-Agent:       Mozilla/5.0 (Windows; U; Win95; en-US; rv:1.8b2) Gecko/20050416
Build Identifier: Mozilla/5.0 (Windows; U; Win95; en-US; rv:1.8b2) Gecko/20050416

For no apparent reason, sometimes, when you hover a link, the mouse pointer and
the back button will go 'crazy'. This happens when you move your mouse over the
link, not just rest on it.

The mouse pointer will constantly shift between the normal mouse pointer and the
hand.

The back button will focus and unfocus itself.

This seems to happen at random on clickable elements. I've had this problem on a
normal link, and on the menus at http://www.nintendo.be/

I filed it as major because it can lead to unpredictable behavior that prevents
you to use the clickable element as normal.

Reproducible: Couldn't Reproduce

Steps to Reproduce:
1. Browse as usual
Actual Results:  
At random, suddenly on a page it will display above described behavior.

Expected Results:  
Leave the back button alone and kept the mouse pointer as a hand.

Comment 1

[Benoît]

I'm now able to reproduce it somewhat.

Go to a page with text links.
Click on one of the links.
Press the back button.
Hover over the links to see if the bug is activated.
If not, repeat.

Comment 2

[Frank Wein [:mcsmurf]]

Yes, confirming...
Any idea when this started to regress? I got some problems reproducing (even
with Comment 1), anyway i see this with the 2005-04-15-06 build.

Comment 3

[Frank Wein [:mcsmurf]]

bz/roc: Possible fallout from Bug 289792?

Comment 4

[Boris Zbarsky [:bzbarsky]]

Possible.  Is it a problem in today's builds?

Comment 5

[Benoît]

Before I used Build 20050416, I used Build 20050409, and didn't notice the
problem there. I usually change builds weekly.

Because of the fixed scroll bar issue, today I got Build 20050418, where the
problem still exists. It seems to even happen more often. I also saw it in
ChatZilla today.

Comment 6

[Robert O'Callahan (:roc) (email my personal email if necessary)]

I'm not able to reproduce this.

Comment 7

[Boris Zbarsky [:bzbarsky]]

I can't reproduce either.  Is this Windows-only?  Frank, can you narrow down
when this broke?

Comment 8

[Frank Wein [:mcsmurf]]

(In reply to comment #7)
> I can't reproduce either.  Is this Windows-only?  Frank, can you narrow down
> when this broke?

I can reproduce, yes might be possible (Windows 2000 here). Narrowing down, well
i can try, the problem is it just happens randomly. On this Bugzilla page here
this just happened on the reply link (on a comment), now i typed something here
in  textbox, hovered link again (and moved mouse), problem was gone.

Comment 9

[Boris Zbarsky [:bzbarsky]]

If you could narrow this down, that would help a lot....

Comment 10

[José Jeria]

(In reply to comment #9)
> If you could narrow this down, that would help a lot....

Works with trunk build 20050414, XP
Broken in trunk build 20050415, XP

I can reproduce each time by:
1. click on any comment link (for example this one, nr #10) on this page
2. press back, and hover any link
3. if bug does not appears, redo the steps. Usually reproducable the second time.

Comment 11

[Boris Zbarsky [:bzbarsky]]

> Works with trunk build 20050414, XP
> Broken in trunk build 20050415, XP

What hours on those dates?

Comment 12

[Peter van der Woude [:Peter6]]

I am somehow unable to reproduce this anymore.
I do have 2 hourly builds for that period though.

firefox-1.0+.en-US.win32_20050414_0931_PDT.zip
firefox-1.0+.en-US.win32_20050415_0257_PDT.zip

I needed I can mail them to narrow the time down

Comment 13

[Peter van der Woude [:Peter6]]

(In reply to comment #12)
covers from 
 20050414 nightly to 
 firefox-1.0+.en-US.win32_20050414_0931_PDT.zip
http://bonsai.mozilla.org/cvsquery.cgi?treeid=default&module=PhoenixTinderbox&branch=HEAD&branchtype=match&dir=&file=&filetype=match&who=&whotype=match&sortby=Date&hours=2&date=explicit&mindate=2005-04-14+06%3A10%3A00&maxdate=2005-04-14+08%3A48%3A00&cvsroot=%2Fcvsroot

covers from 
 firefox-1.0+.en-US.win32_20050414_0931_PDT.zip to
 firefox-1.0+.en-US.win32_20050415_0257_PDT.zip
http://bonsai.mozilla.org/cvsquery.cgi?treeid=default&module=PhoenixTinderbox&branch=HEAD&branchtype=match&dir=&file=&filetype=match&who=&whotype=match&sortby=Date&hours=2&date=explicit&mindate=2005-04-14+08%3A49%3A00&maxdate=2005-04-15+02%3A20%3A00&cvsroot=%2Fcvsroot

covers from
 firefox-1.0+.en-US.win32_20050415_0257_PDT.zip to
 20050415 nightly
http://bonsai.mozilla.org/cvsquery.cgi?treeid=default&module=PhoenixTinderbox&branch=HEAD&branchtype=match&dir=&file=&filetype=match&who=&whotype=match&sortby=Date&hours=2&date=explicit&mindate=2005-04-15+02%3A21%3A00&maxdate=2005-04-15+06%3A16%3A00&cvsroot=%2Fcvsroot

Comment 14

[Ria Klaassen (not reading all bugmail)]

I don't know if this is of any diagnostic use:
if I *only* click this bookmarklet, the weird cursor behaviour stops:
http://slayeroffice.com/?c=/content/tools/removeChildren.html
Hit Escape to stop the bookmarklet.

Comment 15

[José Jeria]

(In reply to comment #12)
> I do have 2 hourly builds for that period though.
> 
> firefox-1.0+.en-US.win32_20050414_0931_PDT.zip
> firefox-1.0+.en-US.win32_20050415_0257_PDT.zip
> 

I tested those 2 builds, works fine in the 20050414_0931_PDT, broken in the
20050415_0257_PDT.

Comment 16

[Peter van der Woude [:Peter6]]

bug 284389 to blame ?

Comment 17

[Boris Zbarsky [:bzbarsky]]

Bug 287616 is more likely.  Could someone seeing this try backing out that patch
and seeing whether that helps?  Again, I can't reproduce this on Linux (but if
this is the bug responsible it's strongly OS-dependent).

Another possibility is bug 289792...

Comment 18

[Frank Wein [:mcsmurf]]

Backing out Bug 289792 "fixed" this bug here.

Comment 19

[Asa Dotzler [:asa]]

roc, can you take a look at this regression? 

Comment 20

[Frank Wein [:mcsmurf]]

Ok here is some debug data, all tests were made on
http://br-online.de/programme/sendungen/, i opened various links in tabs and
closed the tabs (don't know if the tabs really matter).

Output from printf("frame %p, view %p, pt=%d,%d\n", aTargetFrame, aView,
aEvent->point.x, aEvent->point.y) in nsEventStateManager::PreHandleEvent:
Normal hover over a link (and moving mouse):
frame 03861344, view 02D77CD8, pt=2295,35640
frame 03861344, view 02D77CD8, pt=2265,35640
frame 03861344, view 02D77CD8, pt=2235,35640
frame 03861344, view 02D77CD8, pt=2205,35640
frame 03861344, view 02D77CD8, pt=2175,35640
[...]

Hovering over a link (and moving mouse), when this bug occours:
frame 03861248, view 02D77CD8, pt=1665,35025
frame 024CBE28, view 02215A10, pt=18975,1965
frame 024CBE28, view 02215A10, pt=18975,1965
frame 03861248, view 02D77CD8, pt=1635,35025
frame 024CBE28, view 02215A10, pt=18975,1965
frame 024CBE28, view 02215A10, pt=18975,1965
frame 03861248, view 02D77CD8, pt=1605,35025
frame 024CBE28, view 02215A10, pt=18975,1965
frame 024CBE28, view 02215A10, pt=18975,1965
[...]

Frame dump when bug occours:
frame 0456AD98, view 0439F1F8, pt=2160,35550
Text(0)@0456AD98[0,18,T]  {0,0,2130,240} [state=40200030] sc=045610C4 pst=:-moz-n
on-element<
  "Elternsprechstunde"
>
frame 03605C10, view 0303B908, pt=18990,1830
Box(toolbarbutton)(0)@03605C10 {60,0,315,330} [state=804000b0] [content=035A8C58]
 [sc=035A6B04]<
  ImageBox(image)(-1)@03605CD4 {30,45,225,240} [state=000000a0] [content=03609E68
]
  Area(label)(-1)@03605DA4 {285,165,0,0} [state=00d00000] sc=034157E4(i=0,b=0)<
  >
>
frame 0456AD98, view 0439F1F8, pt=2190,35550
Text(0)@0456AD98[0,18,T]  {0,0,2130,240} [state=40200030] sc=042A4A8C pst=:-moz-n
on-element<
  "Elternsprechstunde"
>
frame 03605C10, view 0303B908, pt=18990,1830
Box(toolbarbutton)(0)@03605C10 {60,0,315,330} [state=804000b0] [content=035A8C58]
 [sc=035A6B04]<
  ImageBox(image)(-1)@03605CD4 {30,45,225,240} [state=000000a0] [content=03609E68
]
  Area(label)(-1)@03605DA4 {285,165,0,0} [state=00d00000] sc=034157E4(i=0,b=0)<
  >
>
frame 03605C10, view 0303B908, pt=18990,1830
Box(toolbarbutton)(0)@03605C10 {60,0,315,330} [state=804000b0] [content=035A8C58]
 [sc=0431C724]<
  ImageBox(image)(-1)@03605CD4 {30,45,225,240} [state=000000a0] [content=03609E68
]
  Area(label)(-1)@03605DA4 {285,165,0,0} [state=00d00000] sc=03415138(i=0,b=0)<
  >
>
frame 0456AD98, view 0439F1F8, pt=2160,35550
Text(0)@0456AD98[0,18,T]  {0,0,2130,240} [state=40200030] sc=045610C4 pst=:-moz-n
on-element<
  "Elternsprechstunde"
>
frame 03605C10, view 0303B908, pt=18990,1830
Box(toolbarbutton)(0)@03605C10 {60,0,315,330} [state=804000b0] [content=035A8C58]
 [sc=034157E4]<
  ImageBox(image)(-1)@03605CD4 {30,45,225,240} [state=000000a0] [content=03609E68
]
  Area(label)(-1)@03605DA4 {285,165,0,0} [state=00d00000] sc=03605698(i=0,b=0)<
  >
>
frame 0456AD98, view 0439F1F8, pt=2160,35580
Text(0)@0456AD98[0,18,T]  {0,0,2130,240} [state=40200030] sc=042A4990 pst=:-moz-n
on-element<
  "Elternsprechstunde"
>
frame 03605C10, view 0303B908, pt=18990,1830
Box(toolbarbutton)(0)@03605C10 {60,0,315,330} [state=804000b0] [content=035A8C58]
 [sc=034157E4]<
  ImageBox(image)(-1)@03605CD4 {30,45,225,240} [state=000000a0] [content=03609E68
]
  Area(label)(-1)@03605DA4 {285,165,0,0} [state=00d00000] sc=03605698(i=0,b=0)<
  >
>
frame 03605C10, view 0303B908, pt=18990,1830
Box(toolbarbutton)(0)@03605C10 {60,0,315,330} [state=804000b0] [content=035A8C58]
 [sc=03415138]<
  ImageBox(image)(-1)@03605CD4 {30,45,225,240} [state=000000a0] [content=03609E68
]
  Area(label)(-1)@03605DA4 {285,165,0,0} [state=00d00000] sc=035A6B04(i=0,b=0)<
  >
>
frame 0456AD98, view 0439F1F8, pt=2160,35550
Text(0)@0456AD98[0,18,T]  {0,0,2130,240} [state=40200030] sc=045610C4 pst=:-moz-n
on-element<
  "Elternsprechstunde"
>
frame 03605C10, view 0303B908, pt=18990,1830
Box(toolbarbutton)(0)@03605C10 {60,0,315,330} [state=804000b0] [content=035A8C58]
 [sc=03605698]<
  ImageBox(image)(-1)@03605CD4 {30,45,225,240} [state=000000a0] [content=03609E68
]
  Area(label)(-1)@03605DA4 {285,165,0,0} [state=00d00000] sc=0431C724(i=0,b=0)<
  >
>

Comment 21

[Frank Wein [:mcsmurf]]

(In reply to comment #20)

> frame 024CBE28, view 02215A10, pt=18975,1965
[...]
> frame 03605C10, view 0303B908, pt=18990,1830
> Box(toolbarbutton)(0)@03605C10 {60,0,315,330} [state=804000b0] [content=035A8C58]
>  [sc=035A6B04]<
>   ImageBox(image)(-1)@03605CD4 {30,45,225,240} [state=000000a0] [content=03609E68
> ]
>   Area(label)(-1)@03605DA4 {285,165,0,0} [state=00d00000] sc=034157E4(i=0,b=0)<
>

Ok, found out what these coords are: While testing, i opened some links in new
tabs and then closed those tabs again. Then the bug sometimes happened. Those
coords (~18980, ~1900) belong to the Close button for tabs (the X on the right
in the tab bar).

Comment 22

[Frank Wein [:mcsmurf]]

Just to clarify: Those frames (mentioned in the last two comments) were dumped
while hovering over a link, not while hovering over the close button. So i guess
the frames with the close button don't belong there...

Comment 23

[Chris]

Able to reproduce, Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.8b2)
Gecko/20050422 Firefox/1.0+.

Comment 24

[Robert O'Callahan (:roc) (email my personal email if necessary)]

This is deeply disturbing. Frank (or someone else), can you try backing out the
changes to each file independently, to see which change induces the bug?

Comment 25

[Frank Wein [:mcsmurf]]

Backing out the view/src/nsViewManager.cpp part fixes the problem.

Comment 26

[Robert O'Callahan (:roc) (email my personal email if necessary)]

Attachment: fix?

Frank, can you try this patch (against trunk) and see if it also fixes the
problem?

Comment 27

[Frank Wein [:mcsmurf]]

Looks good, can't reproduce it anymore with this patch.

Comment 28

[Robert O'Callahan (:roc) (email my personal email if necessary)]

Comment on attachment 181907 [details] [diff] [review]
fix?

Something is using the value of event->point after we've finished dispatching
it to views ... maybe in widget? anyway, the safe thing to do is to just always
restore it at the end. This fixes the bug according to Frank.

Comment 29

[Boris Zbarsky [:bzbarsky]]

Comment on attachment 181907 [details] [diff] [review]
fix?

Add a comment about the need to restore the original point here, ok?

Comment 30

[Frank Wein [:mcsmurf]]

Comment on attachment 181907 [details] [diff] [review]
fix?

Fixes regression

Comment 31

[Asa Dotzler [:asa]]

Comment on attachment 181907 [details] [diff] [review]
fix?

a=asa

Comment 32

[Robert O'Callahan (:roc) (email my personal email if necessary)]

checked in

Comment 33

[Ashley Bischoff (blog at handcoding.com)]

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

Comment 34

[Benoît]

I have noticed this behavior some 10 minutes ago again, on Adblock's phpBB
message board. However, I can't seem to reproduce it anymore.

Build 2005050506

Comment 35

[Benoît]

Aha! Now I'm able to reproduce it.

Go to http://adblock.mozdev.org/forum.html/no_wrap

Hover the mouse pointer on a link while the page is loading (may not be
required). Repeat if necessary by pressing Back and loading the URL again (I
loaded it from the pull-down list of the location bar).

You will notice the strange behavior about 50% of the time. It's really random.
I first noticed it in that forum's ReadMe thread. If you click the link to it
while the page is loading, and the page already shows the strange behavior when
hovering the link to it, it will carry over.

Reopeing.

Comment 36

[Steve England [:stevee]]

Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.8b2) Gecko/20050506
Firefox/1.0+
I never saw the original manifestation of this bug, but recently I've been
seeing strangeness when hovering over links; the mouse pointer rapidly changing
between the arrow and the hand icons for no reason. I can't guarantee that it's
not an issue because of either the landing of bug 274784 or an extension problem
related to the landing of bug 274784.

Comment 37

[Benoît]

I feared that someone would step forward and mention the bfcache bug, but since
I had already posted two comments, I thought I would be going too overboard.
Guess I was wrong.

The behavior you describe is exactly the bug described here.

I can confirm that the bfcache bug isn't what causes the regression. I've tested
the bug both with browser.sessionhistory.max_viewers on 10 and 0, and both
showed the bug.

Comment 38

[Daniel C]

I can't reproduce using the steps in comment 35, but I can confirm that I have
seen this bug. I saw it before the patch, after the patch but before the bfcache
landing, and now after the bfcache landing. Unfortunately I cannot reproduce it
consistently. Just sometimes, when hovering over a link, the pointer flips
rapidly between pointer and normal, and the back button OR the close tab widget
flip rapidly between hover and non-hover state...

Comment 39

[Steve England [:stevee]]

Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.8b2) Gecko/20050508
Firefox/1.0+
I think this is the same bug: Go to http://www.liveforspeed.net and left click
on any of the links down the left hand side. Try left clicking on the same link,
then a different link, and sooner rather than later the bug should show itself.

Comment 40

[Frank Wein [:mcsmurf]]

(In reply to comment #39)
> I think this is the same bug: Go to http://www.liveforspeed.net and left click
> on any of the links down the left hand side. Try left clicking on the same link,
> then a different link, and sooner rather than later the bug should show itself.

But i didn't have to move my mouse cursor to see the bug==>different bug, also
some JS seems involved here

Comment 41

[Robert O'Callahan (:roc) (email my personal email if necessary)]

Attachment: fix?

Frank, can you try this patch and see if it solves the problem?

Comment 42

[Frank Wein [:mcsmurf]]

The one on https://www.liveforspeed.net you mean? No.

Comment 43

[Robert O'Callahan (:roc) (email my personal email if necessary)]

how about the one in comment #35?

Comment 44

[Robert O'Callahan (:roc) (email my personal email if necessary)]

Also you could try backing out different parts of the original checkin as you
did in comment #25...

Comment 45

[Frank Wein [:mcsmurf]]

I can't reproduce the one from Comment 35, the https://www.liveforspeed.net one
already occours with a older build from March (2005-03-26). I think we should
really open new bugs for those two bugs and not triage these here...

Comment 46

[Robert O'Callahan (:roc) (email my personal email if necessary)]

yes, please open new bugs for any remaining issues

Comment 47

[Benoît]

bug 294060 handles the remaining issue, so it seems logical that this bug would
be dependant on it.