Tested on build #2001050304 To reproduce: go to the links near the bottom of the page (avoid the simpsons archive link near the top...it will open a new window on mouseover) 1. hover over one of the links making sure to leave room for the page to scroll 2. using the mouse wheel, scroll down quickly 3. Notice that the link you hovered over is still red (the hover color) rather than blue (the normal color) Note: this happens on links that have been either visited or unvisited. The hove color is always red in either case. Jake

Sounds like event problems

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

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

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

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

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

QA contact updated

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

Shouldn't this go to bryner, since it's mousewheel?

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

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

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

See also bug 20022, :hover state not set until mouse move. This bug seems to be specific to using the mouse wheel.

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

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

Marking mostfreq at 11 dups.

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

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

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

Is the problem here that we need to send mousemove (and mouseout/mouseover) events when scrolling with the mousewheel? (i.e., just send the events that would have happened if it had been the mouse moving between the two locations rather than the page moving?)

I think when we scroll by keyboard we're currently doing the mouseout half of that, but not the mouseover half. Or something like that...

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

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

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

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

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

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

Didn't this once work? Like around the 0.9 days? I seem to remember this was once fixed...

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

This is one of the most visible and most duplicated bugs left in mozilla. I am nominating it for 0.9.4.

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

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

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

Simple test case in 96618... attachment 46875 [details]

This bug is fixed for me in build ID : 2001082803 on Win98 SE Can somebody confirm this on other platforms as well ?

Kinda. It de-activates when I scroll out, but the cursor doesn't change (bug 89449). When I scroll back over the link, though, it doesn't re-activate.

I think the test page proposed http://www.visi.com/~hoju/humor.html may be using bad HTML syntax (I'm not sure) cause if you go to http://www.zophar.net the sidebar at the right works now as it should. (It wasn't before) The hover state is de-activated then the other link hover state is activated and you can go back and forth with no problem.

>I think the test page proposed >http://www.visi.com/~hoju/humor.html >may be using bad HTML syntax (I'm not sure) It is curious that you say that my page uses bad html syntax since I provide two images at the bottom of the page that link directly to the xhtml and css validators. My page validates as XHTML Strict and passes css validation without even a single warning. Not sure how much more valid I could make it??? But anyway, to tell you the truth, I haven't experienced the bug in a while. I'll try tomorrow at work where I actually have a mouse with a mouse wheel. Jake

It sure seems to have gone away for me, too. This is using build 2001-08-27-03 under WinNT4sp6, and looking at the page I used to notice this bug on all the time, http://www.opengl.org/discussion_boards/cgi_directory/forumdisplay.cgi?action=topics&number=3&start=here

For me it doesn't seem to be fixed. If you go to the URL http://informer2.comdirect.de/de/news/alle/index.html and scroll over the links located in the center frame you will notice that scrolling with the mouse over another link will not occur another hover state. I've tested it with Build 2001092909 on Win2000SP2. I think that scrolling the mouse should only throw a MouseMove-Event.

For me it doesn't seem to be fixed. If you go to the URL http://informer2.comdirect.de/de/news/alle/index.html and scroll over the links located in the center frame you will notice that scrolling with the mouse over another link will not occur another hover state. I've tested it with Build 2001092909 on Win2000SP2. I think that scrolling the mouse should only throw a MouseMove-Event.

Well, it also does not work at http://www.cnn.com/ (Linux/i386 - 2001082908)

Very true. I didn't realize that the testcase in bug 89449 had additional links down the page! I'll attach a modified version here, where it's easy to confirm that this bug still exists.

Right you are, Dean. The problem with the link remaining in hover color is gone, but if I point at a link then scroll off it, my mouse cursor is indeed still a "hand", rather than the usual arrow, until I move it.

Oh, I didn't see the other testcase.. Mine has many more links, so everybody can now choose according to their preference. I think we have to reevaluate this bug. The problem does not appear any more, however we still do not have optimal behavior. After scrolling off a link, the mouseover color disappears but another mouseover event is not fired if we end up on another link. I am tempted to close this bug as WORKSFORME and open a new one describing the remaining problem in more detail.

The problem appears to be gone. I created bug 98114 as a spinoff to correct the remaining problem of firing another hover state if you end up on top of another link after scrolling.

Perhaps the fix for bug 66617 helped? Or something else?

on build ID: 2001-09-04-00trunk win2k, the mouse wheel is not working for me. I am unable to scroll up and down the page using the mouse wheel. Anybody else seeing this problem?

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

The bug is fixed on build ID: 2001-17-01-05-0.9.4 win2000. marking verified

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

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

It doesn't work for me here on Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.1a) Gecko/20020618 Please note that this is a recent build.

This has indeed regressed on my Linux current CVS build.

I guess this bug needs retargeting then. Just a guess at 1.2a but I thought I might as well put it to the next available milestone while adding myself. Someone in the know may want to put it even further back though?

Reconfirmed using FizzillaCFM/2002072203. Setting Platform=All.

-> me

I have Mozilla build 2002072700 under Linux/PPC and I've just noticed this bug, but it also occurs when I scroll with the keyboard. Mozilla behaves as if the mouse stayed over the same element, so: 1) the color of the link or whatever remains the same, 2) the pointer shape remains the same, 3) new elements under the mouse pointer don't get hovered. In fact this is not related to scrolling, since I have the same problem when navigating with the keyboard. For instance, put the mouse pointer over a link. Hit Alt-left arrow (equivalent to Back) then Alt-right arrow (equivalent to Forward) so that the mouse pointer is back over the link. But the link isn't in :hover state. It seems that the bug occurs when the element under the mouse pointer changes though the mouse pointer hasn't moved.

I'm noticing this as well on 1.2a. Jaguar 10.2.1, Mozilla/5.0 (Macintosh; U; PPC Mac OS X; en-US; rv:1.2a) Gecko/2002091014 -Brett

Not to say this isn't an improvement, but this solves only one half of the problem. Now a link does not remain highlighted when it disappears from under the mouse cursor, however, a new link that appears under the mouse cursor while scrolling does not get highlighted, not even after I stop scrolling. Opera 6 and IE 6 get this right.

Comment on attachment 104210 [details] [diff] [review] patch sr=hyatt

Comment on attachment 104210 [details] [diff] [review] patch r=me

Comment on attachment 104210 [details] [diff] [review] patch a=roc+moz for trunk

checked in.

All the other problems I mentioned in comment 60 remain. I suppose that this bug should be reopened (or should I open a new bug for every problem?).

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

this WFM with 2003041009/win2k. verified. (Vincent - yes, I'm afraid you should file bugs for those other issues if they are still problems with new builds)

FYI, bug 201590 and bug 201591.