This is a spinoff from bug 78765, which I resolved as WORKSFORME. Here is a description of the remaining problem: If you hold the mouse over a link with mouseover property, the link changes state and turns red for example. If you scroll the page so that the cursor ends up over another link that link is not highlighted as should be expected.

All settings are now the same as the original bug. As a sidenote, both Opera 5.12 and IE 5.5 have the original problem of leaving a link in hover state after scrolling. None of them resets the hover state correctly after scrolling. This is our chance to outshine the other browsers!

Note that although 78765 mentioned only mousewheel scrolling, this bug shows itself whether you scroll with the keyboard or the mousewheel.

is bug 98303 about the same thing as this bug?

Here's another remaining issue: Hover a link and use mousewheel to scroll up while on top of page (i.e. you can't scoll up). The link will become "normal", although mouse cursor hasn't moved (nor the underlying page).

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

I am pasting Robert Rainwaters insightful comments from bug 98303 here: When using the wheel on a wheelmouse (Intellimouse) over an element is causing a mouseout event to be fired. Reproducible: Always Steps to Reproduce: 1. Go to http://jsdomapi.sourceforge.net/mozilla/mouse.html 2. Place mouse over the gray element 3. Scroll the wheel on the mouse Actual Results: The mouseout event is incorrectly fired. Expected Results: The mouseout event should not be fired unless there really is a mouseout event.

The second testcase is the same that is available from http://jsdomapi.sourceforge.net/mozilla/mouse.html and described in Robert Rainwaters pasted comment a bit further up. Enjoy your scrolling!

I also tested using a logitech mouse with the same results (mouseout is fired). I guess its possible its the mouse drivers problem and not Mozilla.

I have a M$ Intellimouse Pro, so I guess it is not mousedriver specific.

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

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

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

Bugs targeted at mozilla1.0 without the mozilla1.0 keyword moved to mozilla1.0.1 (you can query for this string to delete spam or retrieve the list of bugs I've moved)

I'm using a Compaq mouse made by Logitech on Win2k, same issue, and yes, IE6 does it right (although I think IE5 had the same bug).

dup of bug 50511?

No, the issue described here is not covered by bug 50511. They are closely related though.

I just marked bug 128065 a dupe of bug 50511. I was going to dupe it to this one before I found the other bug. 128065 was reported on chatzilla originally, and I suspect this bug may be visible in chatzilla, since chatzilla will scroll a page without and mousewheel or keyboard action. Simply place the mouse over a link and wait for traffic in a chat channel to scroll the screen automatically.

.

retargeting

dbaron: did your recent work affect this?

Div2 is the magic point here. It has a dark green background, but the ':hover' state has a light green background. 1. Using the wheel to scroll so that the div2 appears underneath the cursor; it does not change color, nor does the cursor change to the I-beam as CSS specifies. 2. Using the wheel to scroll so that div2 no longer appears beneath the cursor triggers the background color change, but the cursor remains an I-beam. 3. Placing the cursor over div2, then scrolling with the wheel in such a way that div2 remains below the cursor, causes the background to change as if div2 was no longer hovered (which it still is.)

This is WFM with current trunk build and really just a duplicate of bug 20022. *** This bug has been marked as a duplicate of 20022 ***