Closed Bug 294060 Opened 15 years ago Closed 4 years ago

hovering link sometimes triggers strange mouse pointer behavior

Categories

(Core :: DOM: Events, defect, major)

x86
All
defect
Not set
major

Tracking

()

RESOLVED WORKSFORME

People

(Reporter: benoit, Unassigned, NeedInfo)

References

Details

(Keywords: regression, Whiteboard: [steps to reproduce: comment 36])

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

Sometimes, randomly, when hovering links on a page, the mouse pointer will
quickly shift between its normal pointer and the hand icon.

I have tested this with both bfcache on and off, and the results are the same.

Reproducible: Sometimes

Steps to Reproduce:
1. Go to a page with links, for example
http://ftp.mozilla.org/pub/mozilla.org/mozilla/nightly/latest-trunk/
2. Hover a link
3. If the bug doesn't show up, press Back, and repeat from step 1

Actual Results:  
The mouse pointer will quickly shift between the normal mouse pointer and the
hand icon.

Expected Results:  
Keep displaying the hand icon.
OS: other → Windows 95
What's the regression window?

Can you ask around and confirm that this is Windows only?
To be more specific, the mouse will be a "normal pointer" and then on a move
will shift to the hand icon, and then quickly back to the pointer, for some odd
reason highlighting text on the first page where this appears for me seems to
correct it.

I have not yet been able to find reliable "steps to reproduce".  Windows build here.
Sorry for being so late with this.
Certain circumstances prohibited me from doing this sooner.
Anyway...

bug#290673 was checked in on 28 april. 29 april's build was fine.
I mention this because the bugs are similar.

First noted this bug on 5 May. Did a little testing...
02/05 broken
01/05 broken
30/05 broken

The regression window is thus 29/05 -> 30/05.
Still don't know if this is only on Windows, though.

Not sure if it's the same bug, but more frequently, instead of the crazy
pointer/hand switching, it does it once when starting to hover the link.
You would start to touch the link, the hand would show up, you would move one
spot up, and it's the point again. Going back up, it remains a hand consistently.
It may be related.
This bug is a spin-off from bug#290673.
The fix for that bug was checked in on 28 April, and was first present in 29
April's build.

I thought 29 April to work fine, but after trying again today, it does also
contain the symptoms of this bug.

Maybe the first bug was never fixed.

Here are detailed steps that always work for me to reproduce it in less than 5
tries:

Exact steps:
-Be in SeaMonkey, any page.
-Have the Adblock Project forum address in your location bar list.
-Go to the forum through the location bar list.
-Click the Readme topic.
-Go Back to "any page" you were at.
-Repeat.

The key to triggering it is to click the Readme topic or at least have your
mouse on it before it has finished loading.
stephend said he was seeing this too
Status: UNCONFIRMED → NEW
Ever confirmed: true
It happened to me a few times.
Exactly as Benoit describes.
Usualy when I switch from one tab to another it disappears. 

Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.8b2) Gecko/20050702
MultiZilla/1.8.0.1h

Windows 2000
I think this bug needs to be fixed before SeaMonkey ships, because it may look
really unprofessional and weird to people using SeaMonkey. It may also lead to
reduced functionality on elements that require focus to work.
Flags: blocking-seamonkey1.0b?
Keywords: regression
See previous comment for the reason.
Flags: blocking-seamonkey1.0b? → blocking1.8b5?
is this just a SeaMonkey bug? I can't reproduce on Firefox branch builds. 
Please renominate if it can be reproduced on other apps.
Flags: blocking1.8b5?
I haven't seen this bug for quite some while now.
Bug 306149 is a bug with the same symptoms (but with a different way and 100%
reproducable).
Maybe when that one gets fixed, this one also gets fixed.
Depends on: 306149
I see this bug every three days or so. And I use recent nightlies.
Blocks: 290673
(In reply to comment #9)
> is this just a SeaMonkey bug? I can't reproduce on Firefox branch builds. 
> Please renominate if it can be reproduced on other apps.

Same here. Can't reproduce with Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8) Gecko/20051103 Firefox/1.5 ID:2005110303
I'm a bit late with mentioning this, but about a month back I tested on a Firefox 1.5 nightly, and the bug wasn't present there.
I've seen this bug occasionally, but not recently.
*** Bug 321990 has been marked as a duplicate of this bug. ***
Right-click on a link, and select a choice that makes a window appear. Cancel the window. Preferably after the cancel the mouse pointer would be on a link. If the bug has been triggered, moving the mouse pointer on the link makes it rapidly change between the normal pointer and the hand.

While moving the pointer, the mouse functions CreateTimer and SetMouseTrailerWindow get called.

Debug output while moving over a link without the bug triggered:

SetMouseTrailerWindow: 03160408
SetMouseTrailerWindow: 03160408
00100392 - 00100392 - 277 - 225 - 02FD7ED8
SetMouseTrailerWindow: 03160408
00100392 - 00100392 - 276 - 225 - 02FD7ED8
SetMouseTrailerWindow: 03160408
SetMouseTrailerWindow: 03160408
SetMouseTrailerWindow: 03160408
SetMouseTrailerWindow: 03160408
00100392 - 00100392 - 280 - 225 - 02FD7ED8
00100392 - 00100392 - 280 - 225 - 02FD7ED8


Output while the bug is occuring, though I'm not sure if it's helpful:
SetMouseTrailerWindow: 03160408
SetMouseTrailerWindow: 03160408
00100392 - 00100392 - 488 - 435 - 02FD7ED8
SetMouseTrailerWindow: 03160408
SetMouseTrailerWindow: 03160408
SetMouseTrailerWindow: 03160408
SetMouseTrailerWindow: 03160408
00100392 - 00100392 - 492 - 435 - 02FD7ED8
00100392 - 00100392 - 492 - 435 - 02FD7ED8
SetMouseTrailerWindow: 03160408
SetMouseTrailerWindow: 03160408
SetMouseTrailerWindow: 03160408
SetMouseTrailerWindow: 03160408
SetMouseTrailerWindow: 03160408
SetMouseTrailerWindow: 03160408
SetMouseTrailerWindow: 03160408
00100392 - 00100392 - 487 - 433 - 02FD7ED8
SetMouseTrailerWindow: 03160408
SetMouseTrailerWindow: 03160408
SetMouseTrailerWindow: 03160408
SetMouseTrailerWindow: 03160408
SetMouseTrailerWindow: 03160408
SetMouseTrailerWindow: 03160408
SetMouseTrailerWindow: 03160408
SetMouseTrailerWindow: 03160408
SetMouseTrailerWindow: 03160408
SetMouseTrailerWindow: 03160408
00100392 - 00100392 - 480 - 429 - 02FD7ED8
SetMouseTrailerWindow: 03160408
SetMouseTrailerWindow: 03160408
SetMouseTrailerWindow: 03160408
SetMouseTrailerWindow: 03160408
SetMouseTrailerWindow: 03160408
00100392 - 00100392 - 476 - 428 - 02FD7ED8
SetMouseTrailerWindow: 03160408
SetMouseTrailerWindow: 03160408
00100392 - 00100392 - 478 - 428 - 02FD7ED8
SetMouseTrailerWindow: 03160408
SetMouseTrailerWindow: 03160408
SetMouseTrailerWindow: 03160408
SetMouseTrailerWindow: 03160408
SetMouseTrailerWindow: 03160408
00100392 - 00100392 - 483 - 430 - 02FD7ED8
SetMouseTrailerWindow: 03160408
SetMouseTrailerWindow: 03160408
SetMouseTrailerWindow: 03160408
SetMouseTrailerWindow: 03160408
SetMouseTrailerWindow: 03160408
SetMouseTrailerWindow: 03160408
SetMouseTrailerWindow: 03160408
00100392 - 00100392 - 490 - 430 - 02FD7ED8
SetMouseTrailerWindow: 03160408
00100392 - 00100392 - 491 - 430 - 02FD7ED8
00100392 - 00100392 - 491 - 430 - 02FD7ED8
SetMouseTrailerWindow: 03160408
SetMouseTrailerWindow: 03160408
SetMouseTrailerWindow: 03160408
SetMouseTrailerWindow: 03160408
SetMouseTrailerWindow: 03160408
SetMouseTrailerWindow: 03160408
SetMouseTrailerWindow: 03160408
SetMouseTrailerWindow: 03160408
SetMouseTrailerWindow: 03160408
00100392 - 00100392 - 482 - 431 - 02FD7ED8
SetMouseTrailerWindow: 03160408
SetMouseTrailerWindow: 03160408
SetMouseTrailerWindow: 03160408
SetMouseTrailerWindow: 03160408
SetMouseTrailerWindow: 03160408
SetMouseTrailerWindow: 03160408
00100392 - 00100392 - 475 - 431 - 02FD7ED8
SetMouseTrailerWindow: 03160408
SetMouseTrailerWindow: 03160408
SetMouseTrailerWindow: 03160408
SetMouseTrailerWindow: 03160408
SetMouseTrailerWindow: 03160408
SetMouseTrailerWindow: 03160408
SetMouseTrailerWindow: 03160408
00100392 - 00100392 - 468 - 432 - 02FD7ED8
SetMouseTrailerWindow: 03160408
SetMouseTrailerWindow: 03160408
SetMouseTrailerWindow: 03160408
SetMouseTrailerWindow: 03160408
00100392 - 00100392 - 464 - 434 - 02FD7ED8
SetMouseTrailerWindow: 03160408
00100392 - 00100392 - 464 - 435 - 02FD7ED8
SetMouseTrailerWindow: 03160408
SetMouseTrailerWindow: 03160408
SetMouseTrailerWindow: 03160408
SetMouseTrailerWindow: 03160408
SetMouseTrailerWindow: 03160408
00100392 - 00100392 - 469 - 437 - 02FD7ED8
SetMouseTrailerWindow: 03160408
SetMouseTrailerWindow: 03160408
00100392 - 00100392 - 470 - 438 - 02FD7ED8
00100392 - 00100392 - 470 - 438 - 02FD7ED8
00120348 - 00100392 - 470 - 438 - 02FD7ED8
Note, these values are from the 1.8 branch. The unlabelled numbers are from just before the comparison "if (mouseWnd != holdWnd)" in TimerProc and are mouseWnd, holdWnd, mp.x, mp.y and mSingleton.mHoldMouseWindow.
So it looks like this bug is NOT caused by MouseTrailer firing incorrectly.
I saw this recently on Linux (GTK2, SeaMonkey 1.0 - so gecko 1.8.0.2?).  Can't reproduce it though.
OS: Windows 95 → All
Is this fixed on trunk now that 306149 has been fixed?
No, it's still there, though with bug 306149 fixed, it's harder to trigger now.

Here's some information that may prove valuable. Spring Rubber posted:

"I just experienced this bug for the first time while using a build from the 1.0 branch. It actually happened on this very board when I opened the Bugs: Broken thread in a new tab, which, according to my preferences, opens in the background. I noticed that as the mouse flickered while hovering over a link, the tab was shifting in and out of focus. I wonder what made this bug happen all of a sudden."
That story you quoted is from a 1.0 branch(?), apparently. Is this bug still reproducible on current trunk builds?
Why are you asking a question I just answered? Please re-read my comment.
So comment 21 is mentioning that it is still a problem on branch?
AARGH!

roc asked: "Is this fixed on trunk now that 306149 has been fixed?"

I answered: "No, it's still there, though with bug 306149 fixed, it's harder to trigger now."

Then I gave some information that could help in fixing this bug. That it's from branch doesn't matter.
Ok, sorry for misunderstanding you. So this can still be reproduced with current trunk builds, which have the fix for bug 306149.
It just happened to me also, with using the 2006-12-08 build, but it was for 10 seconds or so, and the problem went away when I went out of the content area into chrome and then back into the content area.
I couldn't reproduce it afterwards anymore.
I now saw the crazy mouse personally on a trunk build on my WinXP laptop. Can this bug be squashed once and for all? Read a previous comment for a hint on what may be the issue. A tab reflow or something?
I can now confirm that opening tabs in the background definitely is related to this issue. More often than not, opening a new tab in the background triggers this.
Doesn't bug 363777 relate to the same issue? It is blocked by the old bug 130078, the hope to resolve most of these crazy bugs.
Do you still see this?  I am unable to recreate using FF 3.0

(In reply to comment #30)
> Doesn't bug 363777 relate to the same issue? It is blocked by the old bug
> 130078, the hope to resolve most of these crazy bugs.

363777 has been closed WFM, but 130078 still open
I've just reproduced this rather quickly. As Benoît said, opening a new tab in the background (I use MouseWheel click for it) can show the result: mouse cursor blinks switching arrow/hand icons while moving over any link.

Work-around is the same as for bug 363777 (100% reproducible): right-clicking any link, move mouse cursor over right-click menu and move it back over the link.

Mozilla/5.0 (Windows; U; Windows NT 5.2; en-US; rv:1.8.1.13) Gecko/20080313 SeaMonkey/1.1.9, Modern theme

PS: Seems (bug 130078) there is a workaround patch in FF3 code.
Depends on: 130078
Assignee: events → nobody
QA Contact: ian → events
Can't reproduce in Mozilla/5.0 (Windows; U; Windows NT 5.2; en-US; rv:1.9.1.3pre) Gecko/20090814 SeaMonkey/2.0b2pre
I've just reproduced this on Firefox 3.5.2
Still around in 3.5.5?
Wheee!  I found one series of steps (not ones I've usually taken when this occurs, hopefully this problem isn't caused multiple different ways) to reproduce this at will!

1. Add a bookmark to your bookmarks toolbar for: javascript:alert('focus!')
2. Move your mouse and click on that bookmark.
3. Alert dialog appears.
4. Cursor is still over the bookmark, so bookmark's hover effect happens.
5. Move cursor off bookmark, toward OK in dialog; bookmark's hover effect
   still happens, even tho no cursor above it.  Click OK in dialog.
6. Hover effect on bookmark still occurs even with cursor off the bookmark.
7. Move cursor over a link, get rapidly flickering cursor.
8. Move cursor back over bookmarks toolbar; bookmark hover effect disappears.
9. Move cursor back over links; no flickering occurs.

So (surprise) this seems focus-related.  CCing local focus expert; now that this can be triggered at will, it seems much more likely to be fixable than ever before...
Whiteboard: [steps to reproduce: comment 36]
> So (surprise) this seems focus-related.

The steps you gave don't imply that at all.
For what it's worth (probably nothing at this point), these steps don't reproduce it on SeaMonkey 1.1.17. But the code is bound to have changed since then, anyway. :)
(In reply to comment #37)

Why not?  The alert due to a mouse-click on a hovered element seems fairly important to the steps.
I am using Firefox 3.6.13 on Windows 7 and I discovered a reliable way to trigger this bug. Click your middle mouse button on any page (not on a link) to trigger the auto-scrolling thing. Then, without moving the mouse, click the middle button again. Then hover over a link. You should see the behavior.

In my experience, this usually seems to trigger it, although it occasionally happens seemingly at random. I tried the steps in comment 36 and they didn't work for me.
I am not able to reproduce this issue on 

Version 	47.0b5
Build ID 	20160512003946
User Agent 	Mozilla/5.0 (Windows NT 10.0; WOW64; rv:47.0) Gecko/20100101 Firefox/47.0

Considering the age and the fact that I cannot reproduce this issue, I will mark this as Resolved-Worksforme. Feel free to reopen the bug if this issue is still reproducible on the latest versions.
Status: NEW → RESOLVED
Closed: 4 years ago
Resolution: --- → WORKSFORME
Reporter, WFM?
Flags: needinfo?(benoit)
You need to log in before you can comment on or make changes to this bug.