39762 - [ESM/CSS] onMouseOver handler doesn't check for mouse move

Status: VERIFIED WORKSFORME

(Core :: DOM: Core & HTML, defect, P3)

Description

[Bill McGonigle (not currently reading bugmail; please contact directly)]

If a page is rendered such that an object with an onMouseOver handler lands under 
the mouse, it is activated.  This can happen so quickly the user might not see 
it. This can lead to a loss of control and unintended input.  Netscape 4 will not 
activate the onMouseOver handler unless the mouse is moved slightly. 
I use this in Netscape for a kiosk-type application where a touchscreen is 
pressed, on a "button" graphic. Touching the touchscreen technically moves the 
cursor to that position (though it's invisible).  In Mozilla, one touch will fire  
indefinately though successive screens since the cursor doesn't move, but is over 
a onMouseOver sensitive object each time.  In Netscape, this doesn't happen since 
the user hasn't "moved the cursor" on the current screen.

Comment 1

[Asa Dotzler [:asa]]

confirming, updating component and owner

Comment 2

[Sean Richardson]

Steps to Reproduce:
1. Copy http://www.angular.com/moz_test/mouseover.html to the URL bar.
2. Move the mouse pointer to a position 50-100 px in from the top and
   left edges of the content area.
3. Press the [Enter] key, making sure not to move the mouse.

Actual Reults:
An image will be displayed showing a door whose top half has been opened,
possibly after a flash of another image.

Expected Results:
An image will be displayed showing "Cooper Designs in wrought iron" on a closed 
door. Moving the mouse will show an image where the top half of the door opens.

NN 4.7 gives the expected result; Mozilla 2000-05-18-08-M16 and IE5 do not.

Those wanting an action to happen with no user intervention can use the
onload handler, once bug 22710 is fixed. 

Marking 4xp and moving to "DOM Level 0" component.

Comment 3

[Johnny Stenback (:jst)]

Tom, any ideas on this?

Comment 4

[joki (gone)]

Hmm.  This is a tough one.  There are a number of other bugs open which actually 
call for the opposite behavior to this one.  For example.  When you scroll and 
the mouse ends up over a link they want the link mouseover to activate 
immediately, not after a mousemove.  The behavior you describe is very close to 
the same thing, except of of course that it happens on document load.  Not sure 
which way to go on this one.

Comment 5

[Bill McGonigle (not currently reading bugmail; please contact directly)]

I would argue that the cursor/mouse should be considered, above all, a user-

interface input device, and, as such Mozilla shouldn't do things based on mouse 

position when it would be clear that there is no user intent to perform an action 

(like at page load).  The scrolling example is a bit more complex, since the user 

is performing an action, but they're performing the action of scrolling, not 

moving the mouse over an object, so that probably falls in line.

I'd love to help code a fix, but after a few hours of running through LXR I've 

not managed to divine the event handling model for this.  I'd appreciate 

suggestions - I should probably take this to the newsgroup.

Comment 6

[joki (gone)]

Adding [ESM/CSS] prefix to bugs in EventStateManager with its generated events 
or CSS pseudo-class management.

Comment 7

[ckritzer (gone)]

We (saari, heikki, ckritzer) unfortunately don't have time to deal with this 
particular scenario (touchscreen based system).  Additionally, it is noted that 
a work around would be to navigate onClick instead of onMouseMove.

Comment 8

[ckritzer (gone)]

saari sez:  One more workaround is an onLoad handler which moves your cursor to 
0:0 which will move the mouse before the mouseover fires, and should be 
backwards compatible as well.

Comment 9

[ckritzer (gone)]

Per heikki, saari, ckritzer:
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.

Comment 10

[Bill McGonigle (not currently reading bugmail; please contact directly)]

Just for clarification, onClick isn't a workaround for this since kiosk-type 

touchscreens don't reliably generate clicks though they do generate mouse moves 

reliably.  I'd love to do the simple onLoad handler suggestion, but I thought 

javascript purposely prevents moving the user's cursor.  If someone can point me 

in the right direction I'll try fixing it myself (my project is stalled until I 

can fix it).  Thanks.

Comment 11

[Bill McGonigle (not currently reading bugmail; please contact directly)]

This bug doesn't seem to exist in M17, at least I haven't been able to recreate 
the improper action.  

Comment 12

[Heikki Toivonen (remove -bugzilla when emailing directly)]

Per reporter's comments, I am marking this as worksforme.

Comment 13

[Prashant Desale]

Works for me too. Verified with 2001-020608.