Re: PointerEvents and iframes

I originally missed this thread - sorry.  I just wanted to re-iterate what
I said on the PE call today around this topic.  I agree there are issues
here, but I disagree that "pointer events are brand new" and so we have an
opportunity to deviate from the model used by mouse events.

In my opinion, one of PE's biggest strengths (eg. in contrast to
TouchEvents) is that it's a logical extension of the mouse event model.  It
should generally be fairly easy to convert a large site designed for mouse
events to opt-into using pointer events, probably even in a piecemeal
(pay-for-play) fashion - because of both the mouse event compatibility
mapping, and the fact that PointerEvent derives from MouseEvent and they
share a lot of the same semantics.

Doing something special just for pointer events around iframes would really
complicate this story (eg. could there still be a simple 1:1 mapping
between pointerdown and mousedown events as described in the spec today?).
 So I agree with Jacob that the right path forward here is to work with the
HTML WG on how to solve this class of problems for events generally, and
then have PE stay in sync with the model provided by other DOM events.

Rick

On Tue, Jan 22, 2013 at 2:39 AM, Jacob Rossi <Jacob.Rossi@microsoft.com>wrote:

>  I think the right place for this discussion is the HTML working group as
> most of this behavior is defined there.  In fact, there’s an ongoing
> discussion about this very capability I believe [1]. I do see how pointer
> events are a new surface area, making it easier to consider a change like
> this. But in the end, I think there are valid scenarios where an author
> might want other event types to propagate through.  So a more general
> feature for enabling this is probably a better route.****
>
> ** **
>
> -Jacob****
>
> ** **
>
> [1] https://www.w3.org/Bugs/Public/show_bug.cgi?id=18780****
>
> ** **
>
> *From:* François REMY [mailto:francois.remy.dev@outlook.com]
> *Sent:* Saturday, January 19, 2013 2:22 AM
> *To:* Daniel Freedman; public-pointer-events@w3.org; Jacob Rossi
> *Cc:* Ojan Vafai
> *Subject:* RE: PointerEvents and iframes****
>
> ** **
>
> We could also only propagate events if the browsing context is the same or
> if the document inside the IFRAME has a specific opt-in
> like “X-Frame-Options: allow”.****
>
>  ****
>
> I guess one of the use cases is a drag & drop that goes over an ads, for
> example. Or, in case you are pinch-zooming (the page handles gestures in
> JavaScript not the browser), the gesture should not stop if your fingers go
> over an IFRAME (also, if you start pinching with one of your fingers on an
> IFRAME, it should work).****
>
>  ****
>
> The second use case may be interacting with user components (for now, they
> are often embedded in an IFRAME even if in the future Web Components and
> Shadow DOM will be used for which event retargeting is already planned).**
> **
>
>  ****
>
>  ****
>
>  ****
>
>  ****
>
> *De :* Jacob Rossi
>   *Envoyé :* 19 janvier 2013 01:54
> *À :* Daniel Freedman, public-pointer-events@w3.org
> *Cc :* Ojan Vafai
> *Objet :* RE: PointerEvents and iframes****
>
>  ****
>
> Interesting proposal.  What’s the use case for this? ****
>
>  ****
>
> I think there’s still a bit of a worry in that, while you’re not leaking
> elements, you are still leaking information about the pointer
> location/state.  So, if I knew the UI layout of the page being framed then
> I could surmise what you were interacting with.  Granted, it’s a pretty low
> threat and information sensitive sites should consider using
> X-Frame-Options to prevent this. But it’s still worth consideration.****
>
>  ****
>
> *From:* Daniel Freedman [mailto:dfreedm@google.com <dfreedm@google.com>]
> *Sent:* Wednesday, January 16, 2013 3:29 PM
> *To:* public-pointer-events@w3.org
> *Cc:* Ojan Vafai
> *Subject:* PointerEvents and iframes****
>
>  ****
>
> A classic problem with using iframes is that mouse events will not fire
> over them. This is particularly troublesome for user interaction and
> dragging motions.****
>
>  ****
>
> I've had a few conversations about trying to let iframes use event
> retargeting instead, similar to how events bubble in Shadow DOM (
> https://dvcs.w3.org/hg/webcomponents/raw-file/tip/spec/shadow/index.html#event-retargeting),
> and have been told that there is too much legacy around the "iframe
> blackhole" to change for mouse events.****
>
>  ****
>
> However, since Pointer Events are brand new, maybe we could add this
> iframe event retargeting to the spec. In this scenario, a Pointer Event
> that bubbles through an iframe will have the target changed to the iframe,
> negating the possibility of an information leak to the parent window.****
>
>  ****
>
> Thoughts?****
>