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

RE: PointerEvents and iframes

From: Jacob Rossi <Jacob.Rossi@microsoft.com>
Date: Sat, 19 Jan 2013 00:51:51 +0000
To: Daniel Freedman <dfreedm@google.com>, "public-pointer-events@w3.org" <public-pointer-events@w3.org>
CC: Ojan Vafai <ojan@chromium.org>
Message-ID: <4bde9dfe2a7a449aa6490fe4c700e721@BN1PR03MB021.namprd03.prod.outlook.com>
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 00:54:14 UTC

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