Re: PointerEvents and iframes

Yes, after seeing all the arguments laid out, it does make more sense for
the HTML WG to solve this.
Thanks!


On Tue, Jan 22, 2013 at 8:30 PM, Rick Byers <rbyers@google.com> wrote:

> 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?****
>>
>
>