Re: UI Events - Mouse Events and iframe targetting

It was pointed out to me offline that I didn't include the sample page that
demonstrates the issues with the vendors; to find it you'd need to dig into
the chromium bug; for simplicity I've put it on github. See
http://dtapuska.github.io/iframe-mouse-target/iframe_outer.html


On Tue, Jun 16, 2015 at 4:16 PM, Dave Tapuska <dtapuska@chromium.org> wrote:

> It seems that processing mouse [move|up] events have 3 different
> implementations when involving an iframe in each rendering engine.
>
> I'm soliciting comments and hope we can work on defining some behavior and
> converging our implementations to benefit the web author.
>
> Specifically when an mouse down event occurs inside an iframe; the
> subsequent mouse moves/ups are targeted at different frames when the mouse
> moves outside the bounds of the iframe.
>
> 1) Chrome targets the frame that generated the mouse down frame sometimes
> (but has side effects with prevent default; see http://crbug.com/269917;
> we need to fix this).
> 2) Firefox targets the mouse down frame unless you move into a sibling
> iframe
> 3) IE 11 & Edge target the topmost frame under the mouse move regardless
> of the mouse down operation.
>
> We need to get some clarity written into the specification. As the spec
> indicates the target is:
>
>
>    - Event.target
>    <http://www.w3.org/TR/DOM-Level-3-Events/#widl-Event-target>: topmost
>    event target
>    <http://www.w3.org/TR/DOM-Level-3-Events/#glossary-topmost-event-target>
>
>
> Likewise in Edge/IE 11 you can have a mouse down event in the iframe; but
> the mouse up event occurs in the main frame.
>
> All browsers do not generate a mouse leave/enter on the iframe document
> when the mouse leaves or enters the iframe when a mouse button is
> depressed; this can leave the iframe in an inconsistent state possibly.
>
> So I would expect that the IE 11/Edge implementation is spec compliant.
> However this doesn't necessarily seem correct to the web author point of
> view.
>
> I can see why the target is defined is set to be the iframe that handled
> the mouse down event because if you are dragging something around you might
> not want to start processing mouse move events on the outer frame until the
> mouse is released.  The crbug references google maps embedded inside a page
> as a use case that occurs in the field today.
>
> With respect to hover processing:
> 1) Chrome doesn't generate hover events for items outside of the iframe
> during a mouse down. (Seems incorrect).
> 2) Firefox does the interesting behaviour of generating hover events for
> items not in the parent frame but in sibling frames.
> 3) IE 11 & Edge generate hover on whatever is under the mouse.
>
> The IE 11/Edge implementation seems straight forward. Perhaps some folks
> can confirm that it is as I think it to be.
>
> The Firefox implementation mystifies me why it behaves different between
> the main frame and a sibling iframe is interesting. Perhaps I'm flawed in
> my reproduction step; but some explanation behind this would be appreciated.
>
> The Chrome/WebKit implementation makes sense a little bit of sense to me
> as well; granted it has some weird bugs like hover and prevent default.
>
> dave.
>
>