[whatwg] seamless iframes and event propagation

[Dimitri Glazkov]

On Fri, Dec 14, 2012 at 12:18 PM, Anne van Kesteren <annevk at 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<