W3C home > Mailing lists > Public > public-pointer-events@w3.org > January to March 2013

RE: PointerEvents and iframes

From: François REMY <francois.remy.dev@outlook.com>
Date: Sat, 19 Jan 2013 10:21:32 +0000
Message-ID: <DUB405-EAS2766A32317DBFB596762CE0A5110@phx.gbl>
To: Daniel Freedman <dfreedm@google.com>, "public-pointer-events@w3.org" <public-pointer-events@w3.org>, Jacob Rossi <Jacob.Rossi@microsoft.com>
CC: Ojan Vafai <ojan@chromium.org>
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] 
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.


Received on Saturday, 19 January 2013 10:22:03 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:20:24 UTC