Closed Bug 290673 Opened 19 years ago Closed 19 years ago

hovering link sometimes triggers strange mouse and back button behavior

Categories

(Core :: DOM: Events, defect)

x86
Windows 95
defect
Not set
major

Tracking

()

RESOLVED FIXED

People

(Reporter: benoit, Assigned: roc)

References

Details

(Keywords: regression)

Attachments

(2 files)

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.
Keywords: regression
OS: other → Windows 95
Version: unspecified → Trunk
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.
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.
Assignee: general → events
Status: UNCONFIRMED → NEW
Component: General → DOM: Events
Ever confirmed: true
Product: Mozilla Application Suite → Core
QA Contact: general → ian
bz/roc: Possible fallout from Bug 289792?
Possible.  Is it a problem in today's builds?
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.
I'm not able to reproduce this.
I can't reproduce either.  Is this Windows-only?  Frank, can you narrow down
when this broke?
(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.
If you could narrow this down, that would help a lot....
(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.

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

What hours on those dates?
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
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.
(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.
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...
Flags: blocking1.8b2?
Backing out Bug 289792 "fixed" this bug here.
roc, can you take a look at this regression? 
Assignee: events → roc
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)<
  >
>
(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).
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...
Able to reproduce, Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.8b2)
Gecko/20050422 Firefox/1.0+.
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?
Backing out the view/src/nsViewManager.cpp part fixes the problem.
Attached patch fix?Splinter Review
Frank, can you try this patch (against trunk) and see if it also fixes the
problem?
Looks good, can't reproduce it anymore with this patch.
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.
Attachment #181907 - Flags: superreview?(bzbarsky)
Attachment #181907 - Flags: review?(bzbarsky)
Comment on attachment 181907 [details] [diff] [review]
fix?

Add a comment about the need to restore the original point here, ok?
Attachment #181907 - Flags: superreview?(bzbarsky)
Attachment #181907 - Flags: superreview+
Attachment #181907 - Flags: review?(bzbarsky)
Attachment #181907 - Flags: review+
Comment on attachment 181907 [details] [diff] [review]
fix?

Fixes regression
Attachment #181907 - Flags: approval1.8b2?
Comment on attachment 181907 [details] [diff] [review]
fix?

a=asa
Attachment #181907 - Flags: approval1.8b2? → approval1.8b2+
checked in
Status: NEW → RESOLVED
Closed: 19 years ago
Resolution: --- → FIXED
Flags: blocking1.8b2?
*** Bug 247378 has been marked as a duplicate of this bug. ***
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
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.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
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.
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.
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...
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.
(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
Attached patch fix?Splinter Review
Frank, can you try this patch and see if it solves the problem?
The one on https://www.liveforspeed.net you mean? No.
Also you could try backing out different parts of the original checkin as you
did in comment #25...
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...
yes, please open new bugs for any remaining issues
Status: REOPENED → RESOLVED
Closed: 19 years ago19 years ago
Resolution: --- → FIXED
bug 294060 handles the remaining issue, so it seems logical that this bug would
be dependant on it.
Depends on: 294060
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: