Re: UI Events - Mouse Events and iframe targetting

Thanks Dave,
I've been aware of differences between browsers here for awhile, but only
recently been convinced that it's important that we try to fix this. /cc
Jacob and Olli in case they have specific experience/advice for EdgeHTML
and Gecko respectively.

In particular, I had a great discussion with the Google Maps team about why
this matters to them.  The Google Maps embedded API
<https://developers.google.com/maps/documentation/embed/> lets you host a
map in an iframe on your page.  Here when you click on the map and drag to
pan it, the user really expects that it continues to pan even if the cursor
leaves the frame.  They've got some ugly UserAgent-specific hacks to make
this work on all browsers and these hacks have gotten in the way of us
fixing other interop problems in Chrome.

So, we need some standard interoperable way to enable such a scenario.  But
this doesn't mean we have to do it by default if that's hard to agree on or
likely to cause developer confusion.  Is this scenario possible today in IE
/ Gecko using the non-standard setCapture API
<https://developer.mozilla.org/en-US/docs/Web/API/Element/setCapture>?
Presumably setPointerCapture
<https://w3c.github.io/pointerevents/#pointer-capture> can definitely be
used for this purpose (though the spec is not clear
<https://github.com/w3c/pointerevents/issues/16>).  But I'm not sure we
want to block a solution to these problems on Pointer Events (eg. there
should be some path for Safari as well).

Has there been any discussion about standardizing setCapture?  If IE and
Gecko already have an interoperable implementation here, perhaps we should
consider that a defacto standard and add it to blink too, then change our
mouse event behavior to match IE's?

But still, I think the UI Events spec should be updated to be clear on what
the default behavior for mouse events should be in this regard.

Thoughts?
   Rick


On Mon, Jun 22, 2015 at 1:21 PM, Dave Tapuska <dtapuska@chromium.org> wrote:

> 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
> <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.
>>
>>
>