Closed Bug 78765 Opened 23 years ago Closed 22 years ago

link left in :hover state after being hovered and scrolled off using mouse wheel

Categories

(Core :: DOM: UI Events & Focus Handling, defect)

defect
Not set
normal

Tracking

()

VERIFIED FIXED
mozilla1.3alpha

People

(Reporter: jrspm, Assigned: bryner)

References

()

Details

(Keywords: regression, testcase)

Attachments

(3 files)

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
Assignee: pierre → joki
Component: Style System → Event Handling
QA Contact: ian → gerardok
*** 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. ***
Status: UNCONFIRMED → NEW
Ever confirmed: true
*** Bug 84984 has been marked as a duplicate of this bug. ***
OS: Windows 2000 → All
*** Bug 85517 has been marked as a duplicate of this bug. ***
QA contact updated
QA Contact: gerardok → madhur
*** 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. ***
Target Milestone: --- → mozilla1.0
*** Bug 89486 has been marked as a duplicate of this bug. ***
Marking mostfreq at 11 dups.
Keywords: mostfreq
*** Bug 89877 has been marked as a duplicate of this bug. ***
*** Bug 90365 has been marked as a duplicate of this bug. ***
Summary: link left in :hover state after being hovered and scrolled off using mouse mouse wheel → link left in :hover state after being hovered and scrolled off using mouse wheel
*** 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.
Keywords: mozilla0.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.
Status: NEW → ASSIGNED
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.
Attached file simple testcase
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.
Keywords: testcase
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.
Status: ASSIGNED → RESOLVED
Closed: 23 years ago
Resolution: --- → WORKSFORME
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
Status: RESOLVED → 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.
Status: VERIFIED → REOPENED
Resolution: WORKSFORME → ---
This has indeed regressed on my Linux current CVS build.
Keywords: regression
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? 
Target Milestone: mozilla1.0 → mozilla1.2alpha
Reconfirmed using FizzillaCFM/2002072203. Setting Platform=All.
Hardware: PC → All
-> me
Assignee: joki → bryner
Status: REOPENED → NEW
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
Status: NEW → ASSIGNED
Target Milestone: mozilla1.2alpha → mozilla1.3alpha
Attached patch patchSplinter Review
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
Attachment #104210 - Flags: superreview+
Comment on attachment 104210 [details] [diff] [review]
patch

r=me
Attachment #104210 - Flags: review+
checked in.
Status: ASSIGNED → RESOLVED
Closed: 23 years ago22 years ago
Resolution: --- → FIXED
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)
Status: RESOLVED → VERIFIED
Component: Event Handling → User events and focus handling
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: