Open Bug 50511 Opened 23 years ago Updated 8 months ago

scrolling/app switching under mouse should cause mousemove (cursor change)

Categories

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

Product:
Core
Component:
DOM: UI Events & Focus Handling
Type:
defect

Tracking

()

Milestone:
Future

People

(Reporter: jruderman, Unassigned)

References

Details

(Keywords: dom0, Whiteboard: [Hixie-P2][Hixie-2.0]) 

moving something from under the mouse or (inclusive) to under the mouse should 
trigger onmousemove, onmouseover, and/or onmouseout as appropriate.  for 
example:

- scrolling the page with the keyboard should change the cursor to an insertion 
point if the cursor ends up hovering over some text (ie and ns4x get this 
right; mozilla doesn't)

- scrolling the page with the keyboard should make tooltips go away if the 
mouse is no longer over the thing we're getting a tooltip about, or if another 
object ends up in front of it.  (ie gets this right; ns4x and mozilla don't.)

- onmouseover and onmouseout should trigger after scrolling onto or out of an 
object.  (mozilla and ie both get this right.)

- putting the cursor over text, holding the mouse button down, and then 
scrolling should select text.  (mozilla and ns4x currently do let you scroll, 
and select text as soon as you move the mouse cursor a pixel.  ie prevents you 
from scrolling while selecting or selecting right after scrolling, which is ok 
but makes the behavior complex.)

- holding the mouse button down over a link and then scrolling should make 
the "drag" icon if you scroll far enough.  (in all three browsers, the drag 
cursor appears after you move the mosue several pixels.)

versions tested: mozilla 2000082708, netscape 4.75, ie 5.5 on windows 98.
Reassigning to joki.
Assignee: jst → joki
This bug has been marked "future" because the original netscape engineer working 
on this is over-burdened. If you feel this is an error, that you or another
known resource will be working on this bug,or if it blocks your work in some way 
-- please attach your concern to the bug for reconsideration.
Target Milestone: --- → Future
*** Bug 59066 has been marked as a duplicate of this bug. ***
According to the original poster, looks like this is a 4xp bug. Someone should
add that to the keywords list.
Well, only parts of this bug are 4xp, but I'll add the keyword anyway.  Also 
lowering severity to minor.
Severity: normal → minor
Keywords: 4xp
Parts of this bug are covered by bug 20022.
*** Bug 65345 has been marked as a duplicate of this bug. ***
Status: NEW → ASSIGNED
Summary: scrolling page or moving elements under mouse should act as if mouse has moved → scrolling/app switching under mouse should cause mousemove
*** Bug 59839 has been marked as a duplicate of this bug. ***
Also on win2000.
OS: Windows 98 → All
*** Bug 66635 has been marked as a duplicate of this bug. ***
*** Bug 66635 has been marked as a duplicate of this bug. ***
*** Bug 66728 has been marked as a duplicate of this bug. ***
This bug: 5 dups
bug 20022: 1 dup
bug 28934: 1 dup

Ten bugs total (I think they're all dups of each other), adding mostfreq kw.
Keywords: mostfreq
Changing platform to all since bug 66728, which is a duplicate of this, has the
platform set to all.
Hardware: PC → All
Keywords: dom0
This bug is a duplicate of bug 28934. (or maybe the other way around since this
one has a much better description.)

I created a test case for that bug:
http://bugzilla.mozilla.org/showattachment.cgi?attach_id=19316
*** Bug 28934 has been marked as a duplicate of this bug. ***
Another interesting thing regarding :hover:

Goto an URL using hover (e.g. http://www.w3.org/TR/REC-CSS1 ).

Place your cursor over a link, so that its hover-effect is triggered.
When you now scroll with the mousewheel, the link stays in hover-state.
When you scroll with the arrow keys instead, the link reverts back to normal,
although any new links under the cursor don't change to their hover-state.

The last bit: wheel mouse comment is true (almost have dup'ed it); plus, mouse
cursor
doesn't get updated!
*** Bug 82152 has been marked as a duplicate of this bug. ***
*** Bug 120843 has been marked as a duplicate of this bug. ***
*** Bug 123241 has been marked as a duplicate of this bug. ***
THis belongs to Event Handling.
Status: ASSIGNED → NEW
Component: DOM Level 0 → Event Handling
QA Contact: desale → madhur
*** Bug 125335 has been marked as a duplicate of this bug. ***
*** Bug 129249 has been marked as a duplicate of this bug. ***
*** Bug 131010 has been marked as a duplicate of this bug. ***
*** Bug 136410 has been marked as a duplicate of this bug. ***
*** Bug 136992 has been marked as a duplicate of this bug. ***
*** Bug 137330 has been marked as a duplicate of this bug. ***
QA Contact: madhur → rakeshmishra
*** Bug 140523 has been marked as a duplicate of this bug. ***
*** Bug 141421 has been marked as a duplicate of this bug. ***
*** Bug 146993 has been marked as a duplicate of this bug. ***
Whiteboard: [Hixie-P2][Hixie-2.0]
*** Bug 128065 has been marked as a duplicate of this bug. ***
*** Bug 167324 has been marked as a duplicate of this bug. ***
*** Bug 149959 has been marked as a duplicate of this bug. ***
*** Bug 174608 has been marked as a duplicate of this bug. ***
QA Contact: rakeshmishra → trix
*** Bug 182104 has been marked as a duplicate of this bug. ***
*** Bug 187045 has been marked as a duplicate of this bug. ***
*** Bug 187028 has been marked as a duplicate of this bug. ***
*** Bug 187086 has been marked as a duplicate of this bug. ***
*** Bug 187638 has been marked as a duplicate of this bug. ***
*** Bug 131950 has been marked as a duplicate of this bug. ***
*** Bug 201028 has been marked as a duplicate of this bug. ***
*** Bug 202159 has been marked as a duplicate of this bug. ***
*** Bug 201591 has been marked as a duplicate of this bug. ***
*** Bug 201590 has been marked as a duplicate of this bug. ***
*** Bug 202766 has been marked as a duplicate of this bug. ***
*** Bug 208686 has been marked as a duplicate of this bug. ***
*** Bug 209371 has been marked as a duplicate of this bug. ***
See also bug 20022 ":hover state not set until mouse move"
Depends on: 20022
.
Assignee: joki → saari
QA Contact: trix → ian
http://bugzilla.mozilla.org/show_bug.cgi?id=111647
may be a related bug

it would be great if this got actioned.

how many dupes?? 
*** Bug 216639 has been marked as a duplicate of this bug. ***
*** Bug 216628 has been marked as a duplicate of this bug. ***
Bug 216639 is not a duplicate of this bug
Adding to summary to make this bug a little easier to find.
Summary: scrolling/app switching under mouse should cause mousemove → scrolling/app switching under mouse should cause mousemove (cursor change)
I don't know if this is miscelanious info, but this is the same on 1.4 and 1.5b
(2003082704) on Windows 98
*** Bug 221152 has been marked as a duplicate of this bug. ***
bug 185293 maybe related or a dup, the difference in that case is that the page
loads under the cursor, rather than an already loaded page scrolling such that a
new element is now under the cursor.
*** Bug 227457 has been marked as a duplicate of this bug. ***
Other than some issues with what happens on app switching (that vary between
platforms), what issues are left to fix on this bug now that bug 20022 has
landed?  Or does anyone know exactly what this bug is about?  There are enough
issues here that I'm tempted to mark it invalid.
40+ dupes, 10 votes, and 4XP - why invalid?
A valid bug must have a description whose reader is able to tell what behavior
would need to change for the bug to be considered fixed.
And anyway, most of the votes and duplicates are probably for issues that are
fixed already.
(In reply to comment #0)
> moving something from under the mouse or (inclusive) to under the mouse should 
> trigger onmousemove, onmouseover, and/or onmouseout as appropriate.  for 

It's worth noting that we now fire mouseover and mouseout, but not mousemove. 
Firing mousemove broke the mouse gestures extension and may have broken some
other things.

> - putting the cursor over text, holding the mouse button down, and then 
> scrolling should select text.  (mozilla and ns4x currently do let you scroll, 
> and select text as soon as you move the mouse cursor a pixel.  ie prevents you 
> from scrolling while selecting or selecting right after scrolling, which is ok 
> but makes the behavior complex.)
> 
> - holding the mouse button down over a link and then scrolling should make 
> the "drag" icon if you scroll far enough.  (in all three browsers, the drag 
> cursor appears after you move the mosue several pixels.)

We don't do either of these.  Doing this would require a different way of fixing
bug 233164.  Then again, the right way to fix bug 233164 would probably be not
to scroll when we focus something due to a click.
Assignee: saari → events
*** Bug 266377 has been marked as a duplicate of this bug. ***
Isnt this fixed? Is there any URL where this can be reproduced?
It is not fixed. For instance, if you open a new tab and the document opens with
a link below the mouse pointer, then the pointer is still an arrow instead of a
hand (this has just happened to me!).
I believe that a mousewheel bug that I reported was rolled into this one.

an example resource is: http://www.peepo.com/2k1/mousewheel/

however this was written and reported some years ago, so the code may not be up
to scratch. apologies

probably a sitemap for mouse bugs would be helpful

similarly for keyboard events

and so in fact onfocus

if mozilla is to be accessible this will need a strategic plan regarding event
handling that is public and open to scrutiny
URL TO REPRODUCE BUG:

http://test.bellevuechristian.org

We are using a slightly modified version of the DOM Tooltip code found at
http://www.mojavelinux.com/forum/viewtopic.php?t=127 for our open source
web-calendaring project called Kronophobia.  There seems to be a persistent bug
in Firefox that causes it to not terminate the mouseover when the scrollwheel is
used to move the page up or down.  The result is that the mouseover text is left
on the page and keeps accumulating the more links you mouseover.  I have
installed multiple versions of Firefox and found that some of the nightly
packages in 08 trunk lines and such DID work correctly so I am confused as to
whether the bugfix is just not being propagated or what?

Reproducible: Always
Steps to Reproduce:
1. Put mouse cursor over a calendar event and wait for mouseover
2. Use scrollwheel to scroll the page down
3. Mouseover stays open

Actual Results:  
The result is that the mouseover text is left on the page and keeps accumulating
the more links you mouseover.

Expected Results:  
The mouseover should vanish.  Internet Explorer, certain versions of Mozilla,
certain versions of Firefox, Opera, Konqueror, etc all handle this correctly.
Component: Event Handling → Installer: GRE
Component: Installer: GRE → Event Handling
This was supposed to be fixed on trunk by 20022. Does anyone still see problems
with trunk builds?
A few days ago, I did a CVS checkout and compiled Mozilla, and the problem still
occurs.

Mozilla/5.0 (X11; U; Linux ppc; en-US; rv:1.8a5) Gecko/20041230
Another URL, a screenshot gallery:
http://scr3.golem.de/?d=0408/hl2&a=32842&s=1

Click on the right-arrow-button to advance to the next screenshot. The mouse
cursor changes from hand to arrow although it hovers over a link on the newly
loaded page. Anyway the functionality remains: even it's displayed as an arrow,
a click triggers the link.

BTW, four and a half year ago this bug might have been "minor" and scheduled for
a future release. But that's ages ago. Promote it to a higher level or this bug
will stay there forever.
*** Bug 284940 has been marked as a duplicate of this bug. ***
*** Bug 291711 has been marked as a duplicate of this bug. ***
*** Bug 307292 has been marked as a duplicate of this bug. ***
mouseover should also be triggered after a page change.

e.g. You have the mouse on a link (and you don't move it at all), the page
changes, and the mouse is still the little hand even if it's no longer on a link.
Other than the issues detailed in comment 64 and in bug 20022 comment 125, I'm not sure what's left here.  The comments saying the bug was still present seem to have stopped after Firefox 1.5 shipped, which suggests to me that the people making them were testing using Firefox 1.0.x instead of trunk builds.
I filed bug 346924 for tooltips not appearing after scrolling so that the cursor is over them.
(In reply to comment #77)
> Other than the issues detailed in comment 64 and in bug 20022 comment 125, I'm
> not sure what's left here.

I also see the problem when I put the mouse in the URL dropdown menu and scroll the menu with the scrollwheel, in Firefox 3 beta 2 on Windows XP. Should I file a new bug report for that specific issue?
Assignee: events → nobody
QA Contact: ian → events
Component: Event Handling → User events and focus handling
Severity: minor → S4
You need to log in before you can comment on or make changes to this bug.