123700 - Mouseouts on IFRAME when moving inside IFRAME

Status: VERIFIED FIXED

(Core :: DOM: Events, defect)

Description

[Kirk Parsons]

From Bugzilla Helper:
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.4)
Gecko/20011019 Netscape6/6.2
BuildID:    20011122106

As the mouse is moved over an IFRAME element, a mouseover is generated,
and then a mouseout is generated as the mouse is moved inside the 
IFRAME.  

The problem is that there is no possible way to detect (via mouseover/mouseout
combinations), whether you are inside the IFRAME or
out.  It seems to me that in the most reasonable behaviour of the
browser, wrt generating events, you would be able to see that after receiving a
mouseover for any element, the mouse is inside the IFRAME,
until a mouseout is received on that element.

It's worth noting that another mouseover is generated on the document obj of the
IFRAME, which can then be used to detect that, in fact, the mouse is still over
the IFRAME (if you receive a mouseover on the 
document immediately after you get the mouseout on the IFRAME, then
you know you're still inside the IFRAME).  However, this is limited,
since you cannot attach an event handler to the document in the case
where the IFRAME is coming from a different domain from the parent
document.
This bug is also (I would argue), applicable to the DIV element.  In the
attached test case, a mouseout is also generated from the DIV element that
contains the IFRAME, as the mouse is moved inside the IFRAME.  In this case, IE
5.5's behaviour is also flakey, in that like Mozilla it generates a mouseout on
the DIV as you go inside the IFRAME, but it then immediately generates another
mouseover.  This means, that you can at least detect that the mouse is still
over the DIV, whereas in Mozilla, you receive a mouseover, then a mouseout, and
never generating any further mouseovers.



Reproducible: Always
Steps to Reproduce:
1.In the attached test case (IFrameMouseoverTest.htm) move the mouse slowly over
the border of the IFRAME to the interior of the IFRAME
2. The sequence of events generated (and reported in the table in the bottom of
the test page) is as follows: (OV=mouseover, OT=mouseout

DIV OV, DIV OT, IFRAME OV, DIV OV, DIV OT, IFRAME OT, IFRAME DOC OV



Actual Results:  Events generated as listed above.

Expected Results:  Mouse events should be generated in the following sequence (I
believe):

DIV OV, IFRAME OV, IFRAME DOC OV

IE 5.5's sequence is:

DIV OV, DIV OT, IFRAME OV, DIV OV, IFRAME DOC OV

Comment 1

[Kirk Parsons]

Attachment: Testcase as described in the description

The contents of the zip file attached are two .htm files, one being the main
test file (IFrameMouseoverTest.htm) and the other being a small file for the
IFRAME src attribute to point to (SimplePop.htm).  These test files are the
same HTML as the URL field, but are made available to those outside the
Netscape firewall.

Comment 2

[Kirk Parsons]

Adding CC & DIGBug to Status Whiteboard.

Comment 3

[Bob Clary [:bc] (inactive)]

Attachment: SimplePop.htm from zip file

Comment 4

[Bob Clary [:bc] (inactive)]

Attachment: IFrameMouseoverTest.htm from zip file

Comment 5

[Bob Clary [:bc] (inactive)]

Attachment: Minor HTML Errors corrected in IFrameMouseoverTest.htm

Comment 6

[Bob Clary [:bc] (inactive)]

HTML1
  IFRAME1 contains HTML2

As soon as the mouse enters the IFRAME1, there is a mouseover generated for the
HTML2 element in HTML2, and then a mouseout is generated for the IFRAME1 in HTML1.

Note there are also some strange behaviors with respect to AT_TARGET and
BUBBLING_PHASE in HTML2 which I haven't figured out yet.

Comment 7

[Bob Clary [:bc] (inactive)]

Consider the following setup

HTML1
  DIV1
    IFRAME1 contains HTML2

HTML2
  DIV2
    #text

Move mouse HTML1->DIV1->IFRAME1->HTML2->DIV2->#text and out again

Mozilla 2002 02 05 AT TARGET Events (+ means more than one)

HTML1   mouseover
HTML1   mousemove+
HTML1   mouseout
DIV1    mouseover
DIV1    mousemove+
DIV1    mouseout
IFRAME1 mouseover
IFRAME1 mousemove+
HTML2   mouseover
HTML2   mousemove
IFRAME1 mouseout   <-- Bad
HTML2   mousemove+
HTML2   mouseout
DIV2    mouseover
DIV2    mousemove+
DIV2    mouseout   <-- hit #text
DIV2    mouseover  <-- left #text
DIV2    mousemove+
DIV2    mouseout
HTML2   mouseover
HTML2   mousemove+
IFRAME1 mouseover
IFRAME1 mousemove
HTML2   mouseout  <-- out of sequence?   
IFRAME1 mousemove
IFRAME1 mouseout
DIV1    mouseover
DIV1    mousemove+
DIV1    mouseout
HTML1   mouseover
HTML1   mousemove+
HTML1   mouseout

Looks like when moving from one container to another, a mouseout event fires on
the "from container" *after* a mouseover and a mousemove fire on the "to container".

This is in addition to the problem where the *Bad" mouseout is fired on the
Container when mouseover/mousemove on the contained object.

Suspect?
http://lxr.mozilla.org/seamonkey/source/content/events/src/nsEventStateManager.cpp#2029

Comment 8

[Bob Clary [:bc] (inactive)]

nominating for nsbeta1

Comment 9

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

Major corporations depend on eapp bugs, and need them to be fixed before they
can recommend Mozilla-based products to their customers. Adding nsbeta1+ keyword
and making sure the bugs get re-evaluated if they are targeted beyond 1.0.

Comment 10

[Bob Clary [:bc] (inactive)]

eapp was incorrectly used to change this to nsbeta1+. Resetting to nsbeta1 to
nominate. This is an important issue and deserves to be nsbeta1+ by the ADT.

Comment 11

[Michael Dunn]

INternal Reference:
http://bugscape.netscape.com/show_bug.cgi?id=12130

Comment 12

[selmer (gone)]

No comments since 5/7 and ETA of 6/4 is long past.  Please update the status of
this bug.

Comment 13

[saari (gone)]

Tom was looking at this on Friday, and he'll be back tomorrow (out today).
Should get and update then

Comment 14

[joki (gone)]

Attachment: Proposed patch

Proposed partial fix / workaround.  It is very difficult within our codebase to
avoid the OS level mouseout events we're receiving upon moving into IFRAME
native windows.  As a workaround we're instead firing additional mouseover/out
events upon entry into the IFRAME.  This isn't entirely clean but does give
reliable state information regarding whether the cursor is within the IFRAME or
not.  I'm going to go with this and we'll see if its an acceptable alternative.

Comment 15

[Johnny Stenback (:jst)]

Comment on attachment 87596 [details] [diff] [review]
Proposed patch

sr=jst

Comment 16

[harishd]

Comment on attachment 87596 [details] [diff] [review]
Proposed patch

r=harishd

Comment 17

[joki (gone)]

Checked into tip.  Needs verification to see if this workaround is sufficient.

Comment 18

[Vladimir Ermakov]

Its much better now. Verifying on build 2002-06-14-08-trunk.

Comment 19

[Jaime Rodriguez, Jr.]

Resolving as verfied because this has been checked into the trunk, and verified
by vladimire.

Comment 20

[Jaime Rodriguez, Jr.]

see my last comment and #18 From Vladimir Ermakov.

Comment 21

[scottputterman]

adding adt1.0.1+.  Please get drivers approval before checking in.

Comment 22

[Judson Valeski]

please checkin to the 1.0.1 branch. once there, remove the "mozilla1.0.1+"
keyword and add the "fixed1.0.1" keyword.

Comment 23

[Jaime Rodriguez, Jr.]

branch approval for this was provided last week. pls check this in asap. thanks!

Comment 24

[scottputterman]

Please check this in today. 

Comment 25

[joki (gone)]

I updated my tree to check this in and found that its partially dependent on a
previous fix not present in the 1.0 branch.  The difference doesn't affect the
substance of the patch, just a matter of using a different approach to get to a
pointer for the IFrame content.  I'm looking into an efficient way to do this
(the later patch provided a convenient function to do it in one method call). 
Should have an update this evening.  The functionality of the patch is unchanged
and I'd recommend continuing with this fix.

Comment 26

[scottputterman]

Lowering impact to ADT2 rtm.  Let's still pursue this for this release but not
treat it as a stop ship.

Comment 27

[joki (gone)]

Attachment: Modified patch for 1.0 branch

Comment 28

[Jaime Rodriguez, Jr.]

removing the "+", for right now, so this stays on our radar. 

have we sent out for reviews on the modified patch for the branch?

Comment 29

[Paul Wyskoczka]

Removing adt1.0.1. Renominate after getting r= and sr= for new patch.

Comment 30

[Randell Jesup [:jesup] (needinfo me)]

This either needs to get reviewed NOW and adt+'d, or it will not be in 1.0.1; 
it's been in trunk/1.1 since June.