Closed
Bug 294060
Opened 20 years ago
Closed 9 years ago
hovering link sometimes triggers strange mouse pointer behavior
Categories
(Core :: DOM: Events, defect)
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.
What's the regression window?
Can you ask around and confirm that this is Windows only?
Comment 2•20 years ago
|
||
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.
Comment 5•19 years ago
|
||
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?
Comment 9•19 years ago
|
||
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?
Comment 10•19 years ago
|
||
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
Reporter | ||
Comment 11•19 years ago
|
||
I see this bug every three days or so. And I use recent nightlies.
Comment 12•19 years ago
|
||
(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
Reporter | ||
Comment 13•19 years ago
|
||
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.
Reporter | ||
Comment 15•19 years ago
|
||
*** Bug 321990 has been marked as a duplicate of this bug. ***
Reporter | ||
Comment 16•19 years ago
|
||
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?
Reporter | ||
Comment 21•18 years ago
|
||
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."
Comment 22•18 years ago
|
||
That story you quoted is from a 1.0 branch(?), apparently. Is this bug still reproducible on current trunk builds?
Reporter | ||
Comment 23•18 years ago
|
||
Why are you asking a question I just answered? Please re-read my comment.
Comment 24•18 years ago
|
||
So comment 21 is mentioning that it is still a problem on branch?
Reporter | ||
Comment 25•18 years ago
|
||
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.
Comment 26•18 years ago
|
||
Ok, sorry for misunderstanding you. So this can still be reproduced with current trunk builds, which have the fix for bug 306149.
Comment 27•18 years ago
|
||
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.
Reporter | ||
Comment 28•18 years ago
|
||
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?
Reporter | ||
Comment 29•18 years ago
|
||
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.
Comment 30•18 years ago
|
||
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.
Comment 31•16 years ago
|
||
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
Comment 32•16 years ago
|
||
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.
Updated•15 years ago
|
Assignee: events → nobody
QA Contact: ian → events
Comment 33•15 years ago
|
||
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
Comment 34•15 years ago
|
||
I've just reproduced this on Firefox 3.5.2
Comment 35•15 years ago
|
||
Still around in 3.5.5?
Comment 36•15 years ago
|
||
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]
Comment 37•15 years ago
|
||
> So (surprise) this seems focus-related.
The steps you gave don't imply that at all.
Reporter | ||
Comment 38•15 years ago
|
||
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. :)
Comment 39•15 years ago
|
||
(In reply to comment #37)
Why not? The alert due to a mouse-click on a hovered element seems fairly important to the steps.
Comment 40•14 years ago
|
||
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.
Comment 41•9 years ago
|
||
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: 9 years ago
Resolution: --- → WORKSFORME
You need to log in
before you can comment on or make changes to this bug.
Description
•