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

Re: [whatwg] seamless iframes and event propagation

From: Anne van Kesteren <annevk@annevk.nl>
Date: Wed, 5 Dec 2012 12:16:01 +0100
Message-ID: <CADnb78hUVNDpEpxtb658XyeahVAsOx4iKLxiO1epW5W3MsDc0Q@mail.gmail.com>
To: Hayato Ito <hayato@chromium.org>
Cc: whatwg <whatwg@lists.whatwg.org>, Eric Seidel <eric@webkit.org>, Ian Hickson <ian@hixie.ch>, Adam Barth <w3c@adambarth.com>, Ojan Vafai <ojan@chromium.org>
On Wed, Dec 5, 2012 at 11:54 AM, Hayato Ito <hayato@chromium.org> wrote:
> Shadow DOM's event retargeting in WebKit uses one Event object for
> every shadow trees.
> When crossing shadow boundaries, an Event object's target (or
> relatedTarget) is set to the appropriate one, but the event object
> itself is reused.

Interesting. Does Shadow DOM have a concept of events that are private
to the shadow tree or does everything leak?

Also, if you change the target you need to adjust mouse coordinates
and such as well. How does that work? Does that also happens if I
dispatch a synthetic event using dispatchEvent()?

(Not having thought much about it this seems especially hairy for
elements from the ordinary node tree that interleaved via a <content>

But if Shadow DOM shares the Event object we should probably introduce
a flag (e.g. a reuse Event object flag) next to the cross-boundary
event parent pointer.

> There, I created an Event object per frame. You can see the design in
> the ChangeLog of the patch. Please don't take it seriously. It should
> be considered as just an experiment at this stage.
> https://bugs.webkit.org/attachment.cgi?id=168866&action=review

The design Ian and I thought out is the same as far as calculating the
dispatch tree goes and the same as far as what the result would be of
invoking preventDefault() and such.

What seems different is that Ian and I envisioned this to work for all
events. And what seems unclear is what if anything is different
between the clones of the Event object.

Received on Wednesday, 5 December 2012 11:17:48 UTC

This archive was generated by hypermail 2.4.0 : Wednesday, 22 January 2020 16:59:50 UTC