W3C home > Mailing lists > Public > whatwg@whatwg.org > July 2012

Re: [whatwg] seamless iframes and event propagation

From: Ojan Vafai <ojan@chromium.org>
Date: Fri, 13 Jul 2012 14:38:01 -0700
Message-ID: <CANMdWTukuwecuLntMgfYOBqe3Qb2jLG4hUQzfww2wB6Q=Rpqgw@mail.gmail.com>
To: Adam Barth <w3c@adambarth.com>
Cc: whatwg <whatwg@lists.whatwg.org>, Eric Seidel <eric@webkit.org>
It's been pointed out to me that what I'm asking for is essentially the
same retargeting as we do for shadow DOMs in web components, where the
iframe is the shadow host and the document is the shadow root. This covers
all the details of what properties need to be updated when crossing the
document boundary. The only addition on top of that is that we need to
convert the coordinate space of mouse events appropriately when we cross
the boundary.

http://dvcs.w3.org/hg/webcomponents/raw-file/tip/spec/shadow/index.html#event-retargeting

Ojan


On Mon, Jul 9, 2012 at 4:26 PM, Ojan Vafai <ojan@chromium.org> wrote:

> I'd like to see us add event propagation into the parent document for
> seamless iframes, e.g. key and mouse events inside a seamless iframe should
> be refired on the iframe element.
>
> Use-case 1: A global key event handler for keyboard shortcuts. Without
> propagating the events, you need to add a key handler to each seamless
> iframe's root in order for these keyboard handlers to work when the iframe
> has focus.
>
> Use-case 2: A dragging UI. Without event propagation, if you don't add
> handlers to the iframe's root, you would just stop dragging when the mouse
> is over seamless iframes. In addition, the coordinates of the mouse event
> should be changed to the parent document's coordinate space when it is
> refired on the iframe, otherwise your code needs to know when it's over an
> iframe.
>
> We should fire two events. One inside the iframe and one on the iframe
> element itself (in the parent document). Any pointers to DOM nodes in the
> event would need to be nulled out in the event fired in the parent document
> if the seamless iframe is cross-domain and non-CORS accessible.
>
> This makes seamless iframes more seamless. Most existing keyboard shortcut
> and dragging JS code would magically keep working without needing to know
> anything about seamless.
>
> Use-case 3: Making an email client that wants the content of the email
> isolated from the client's UI, but doesn't want a nested scrollbar (i.e.
> the editable area sizes to the emails size). In this case, you don't want
> to inherit the CSS for the mail client into the email's content. Similarly,
> you may not want your global keyboard handlers to run when typing in the
> editable area.
>
> Similar to Adam's allow-seamless proposal, I'd like to see seamless have
> the ability to tweak which bits of the frame act seamlessly. Adam's
> proposal has inherit-styles. We could also add propagates-events to
> allow-seamless. Both of those would be off by default. For seamless, we
> could have no-inherit-styles and no-propagate-events in order to disable
> either behavior, also off by default.
>
> Ojan
>
> On Sat, May 26, 2012 at 5:16 PM, Adam Barth <w3c@adambarth.com> wrote:
>
>> Hi whatwg,
>>
>> I've added a proposal to the wiki
>> <http://wiki.whatwg.org/wiki/AllowSeamless> about letting a document
>> indicate that it is willing to be displayed seamlessly with a
>> cross-origin parent.  This proposal is a refinement of the approach
>> previously discussed in this thread:
>> <http://old.nabble.com/crossorigin-property-on-iframe-td33677754.html>.
>>
>> Let me know if you have any feedback.
>>
>> Thanks!
>> Adam
>>
>
>
Received on Friday, 13 July 2012 21:38:52 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Wednesday, 30 January 2013 18:48:09 GMT