RE: PointerEvents and iframes

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<mailto: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]
Sent: Wednesday, January 16, 2013 3:29 PM
To: public-pointer-events@w3.org<mailto: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?