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

Re: [whatwg] seamless iframes and event propagation

From: Dimitri Glazkov <dglazkov@chromium.org>
Date: Mon, 17 Dec 2012 13:48:19 -0800
Message-ID: <CADh5Ky3t70g9PC-iUJqLEBBUOm4CHtOWaMY=M4zrgLbmhXtEjQ@mail.gmail.com>
To: Anne van Kesteren <annevk@annevk.nl>
Cc: Hayato Ito <hayato@chromium.org>, 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 Fri, Dec 14, 2012 at 12:18 PM, Anne van Kesteren <annevk@annevk.nl>wrote:

What would help me is to better understand the requirements of the
> shadow DOM with respect to event dispatch. To calculate the dispatch
> tree, you're using the event type, right? Then at certain points
> you're also making modifications to the Event object being dispatched,
> correct? Is there anything else? I'd like to expose those as hooks
> from the dispatch algorithm, but I'd like to make sure I'm not missing
> anything.
>

Okay. Here is all the shadow DOM-related monkeypatching:

1) When dispatching events (http://dom.spec.whatwg.org/#dispatching-events),
on step 4, the *event path* is built using
http://dvcs.w3.org/hg/webcomponents/raw-file/tip/spec/shadow/index.html#dfn-retargeting-algorithm,
and is actually a list of tuples, storing a *relative target* in addition
to *ancestor*.

2) When invoking event listeners (
http://dom.spec.whatwg.org/#concept-event-listener-invoke), on step 3, we
initialize event's *currentTarget* and *target* attributes to the *relative
target* for the *ancestor* on which the listeners are invoked (consulting
the list of tuples computed in item 1).

3) Also when invoking event listeners (
http://dom.spec.whatwg.org/#concept-event-listener-invoke), between steps 3
and 4, we have to:

a) if the type of event is *MouseEvent*, adjust offsetX and offsetY
relative to *relative target*.

b) If the type of event has a *relatedTarget* attribute (*MouseEvent*, *
FocusEvent*), adjust it using
http://dvcs.w3.org/hg/webcomponents/raw-file/tip/spec/shadow/index.html#dfn-related-target-algorithm
.

4) The step 7 of
http://dom.spec.whatwg.org/#concept-event-listener-invokemay actually
happen more than once, since
*relative target* and *ancestor* always equal each other whenever the node
is a shadow host.

5) Finally, whenever adjusted *relatedTarget* and *target* are the same,
skip step 9.3 of http://dom.spec.whatwg.org/#concept-event-listener-invoke.
The intent here is to not invoke event listeners on nodes where adjusting
both relatedTarget and target resulted on them being the same node -- to
prevent widgets sending out useless mouseovers/outs when the user is
hovering inside of it.

I think that's it :)

:DG<
Received on Monday, 17 December 2012 21:48:49 UTC

This archive was generated by hypermail 2.3.1 : Monday, 13 April 2015 23:09:18 UTC