32415 - [DOM] mouseover="alert('foo')" blocks the firing of mouseout

Status: RESOLVED WORKSFORME

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

Description

[John Morrison]

Overview Description:
  onmouseover="alert('foo')" blocks the firing of onmouseout for the same 
element.

Steps to Reproduce:
1) open the attachment (to follow)
2) move the mouse over and then out of the yellow DIV on the page

Actual Results:
  An alert dialog that says 'mouse over' is thrown. 

Expected Results:
  An alert dialog that says 'mouse over' is thrown, followed by an alert dialog
  that says 'mouse out' (i.e., the alert box does not block the firing of the 
  onmouseout event. 

 Note: it is possible to move the mouse on Mozilla such that more than one alert
 box is thrown up (all on mouseover events). When dismissing them, it may appear
 that clicking on the OK has no effect, but this is simply a consequence of 
having
 multiple alert boxes stacked at the same screen x/y position. 

Reproducibility: always

Build Date & Platform Bug Found:
  2000031809  win98 trunk commercial
  2000031809  linux rh 6.0 trunk commercial
  2000031809  macos 8.6 trunk commercial

  For comparison, both events fire and both alerts are thrown by Nav 4.73 on 
  win98.

Additional Information:

 This bug is a "leftover" from bug #29353. 

 From bug #29353: 
  ---- Additional Comments From [e-mail] 2000-03-17 21:59 ----
  ... I also see what you're describing with the mouseout event that's
  missed if mouseover brings up an alert. My guess is the intervening
  alert window confuses the issue. It sounds like a focus problem that I'd
  give to saari.
  ----   

To be honest, I don't have a use case in mind for this scenario, but the
4.x behaviour appears to be the correct one. This also seems more like a
DOM issue really -- CC: saari. (Apologies if I put this in the wrong
component).

Comment 1

[John Morrison]

Attachment: testcase; alert onmouseover blocks onmouseout from firing

Comment 2

[Johnny Stenback (:jst)]

Tom, I think this one belongs to you, reassigning...

Comment 3

[joki (gone)]

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

Comment 4

[ekrock's old account (dead)]

Nominating nsbeta2. We have to start drawing a line on DOM0 backward 
compatibility; these bugs are supposed to be a high priority for nsbeta2 per the 
beta2 criteria.

Comment 5

[ekrock's old account (dead)]

Setting to [nsbeta3+].

jgrm -- One question: bringing up an alert for a mouseover would be pretty 
unusual on the web; modal alerts are universally frowned upon on web pages. If 
the firing of onmouseover with *any* code is blocking later mouseouts, that's a 
source of deep concern. e.g. that would cause image rollovers to fail. However, 
if it's only the use of alert in particular that causes this, it's a pretty low 
priority, possibly even FUTURE--I think alert on onmouseover will be very rare 
on the web.

Could you experiment and determine whether it's just alert itself that's causing 
the problem? Marking [NEED INFO].

Comment 6

[Peter Trudelle]

[nsbeta2-] nominating for nsbeta3

Comment 7

[John Morrison]

I did try to find another situation that produces this behaviour but could not
find one. As I originally noted -- "To be honest, I don't have a use case in 
mind for this scenario, but the 4.x behaviour appears to be the correct one." 

This falls into undefined behaviour, but, all things being equal, implementing
this in a way that is compatible with nav4.x and IE would be preferable. 

[Of course, all things are not equal, and time + priorities may dictate that 
it is acceptable to drop the mouseout in this case].

Comment 8

[joki (gone)]

This works on my working tree.  Not sure why.  Investigating.

Comment 9

[joki (gone)]

Okay, still not sure why this works now but in my latest tip build its okay.  
There is still the issue that multiple alerts can be put up at once but that is 
dealt with in bug 31889.  I now get an alert for each mouseover and mouseout of 
the div on WinNT.  I'm marking this WORKSFORME.

Comment 10

[John Morrison]

This literally started working since this morning. The morning verif. builds
did not do fire both events, but it's working in the evening verif. build on 
win32. (I haven't checked other platforms).

Comment 11

[joki (gone)]

Unfortunately I've found why this works.  The alert dialogs have become 
non-modal and they will be going back to being modal.  This is still working but 
I'm reopening it.

Comment 12

[joki (gone)]

So the current status is this:

1) The mouseover state isn't set until after the alert box (and all other DOM 
calls) are done.  So as a result when the alert is fired the current state isn't 
yet set.

2) If I fix the above so that the state is set before the DOM call we will 
immediately get a mouseout when the alert box opens.  The problem with this is 
that even if the mouse is left over the link the whole time it will give another 
mouseover as soon as it is moved after the alert is closed, thus firing another 
alert and so on ad infinitum.

Not sure how to proceed with this one.  As long as the alerts are modal its 
difficult to prevent the instant mouseout event.  If they're not prevented then 
some method would need to be devised such that we know to suppress the mouseout 
without resetting our internal data so that after the alert is closed we could 
continue from the same state we had before the alert.

Comment 13

[joki (gone)]

Adding [DOM] prefix to bugs related to DOM Level 0, 1, or 2 
compatibility/compliance.

Comment 14

[Nisheeth Ranjan]

As noted earlier by John, we don't have a important use case for this bug.  
Futuring unless somebody objects...

Comment 15

[Nisheeth Ranjan]

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 16

[Prashant Desale]

Nominating for nsbeta1, since nsbeta2,3, dogfood, rtm keywords are going to be 
cleared soon and important bugs could loose attention. I think this one deserves 
nsbeta1 nomination.

Comment 17

[joki (gone)]

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

Comment 18

[Jonathan S Abrams]

Chanigng platform and os to reflect the scope of bug 65337, which was deemed as
a duplicate of this.

Comment 19

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

nsbeta1-, but would be nice to have for 1.0.

Comment 20

[Asa Dotzler [:asa]]

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)

Comment 21

[Jan Derk]

onMouseOut also does not get called if onMouseOver makes a call to
cur.style.MozOpacity. 

This page shows it:
http://www.dynamicdrive.com/dynamicindex4/image5.htm

Now the stupid mouseover trick is broken ;)

Comment 22

[Stephan Tolksdorf]

Jan, I just stumbled over the same problem.

Doesn't this annoying bug belong into a seperate bug report?

Comment 23

[Jan Derk]

I don't think so, because to me this seems be the same bug, but I am not a
Mozilla hacker. So I better leave this to the Mozilla development team to decide
this.

Setting a new target milestone would make sense though ;)

Jan Derk

Comment 24

[Wayne Mery (:wsmwk)]

still fails, i.e. second alert pops but 31889is blocked.

SM trunk Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a1) Gecko/20051124 SeaMonkey/1.5a

Comment 25

[sjw]

Is this one a wontfix?

Comment 26

[[ex-Mozilla] Agi Sferro | :agi]

It looks like it's working in Firefox31.