[whatwg] seamless iframes and event propagation

[Dimitri Glazkov]

On Tue, Jan 8, 2013 at 6:26 AM, Anne van Kesteren <annevk at annevk.nl> wrote:
> On Mon, Dec 17, 2012 at 10:48 PM, Dimitri Glazkov <dglazkov at chromium.org> wrote:
>> 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.
>
> If you have a tree such as <a> -> <shadow> -> <b> -> <shadow> and an
> event is dispatched in <b>'s <shadow> event's target is only adjusted
> on <b> right? It does not need to be adjusted further for <a>'s
> <shadow> or <a>?

Does <shadow> stand for the actual <shadow> element (the shadow
insertion point) or the shadow root in your diagram? I think what
you're trying to ask is this...

1) For a tree <a> -- [shadow root] -> <b> -- [shadow root] -> <c>
(where "->" denotes child-parent relationship and "--" denotes
host-root relationship)
2) if an event is dispatched on <c>
3) where is the event target's adjusted?

If that's the question, then it needs to be adjusted twice: at <b>
(the adjusted target becomes <b>) and at <a> (the adjusted target
becomes <a>).

>
>> 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.
>
> Are you sure this happens at that point? Because at that point the DOM
> could have completely changed due to event callbacks.

That's a good point. In WebKit implementation, the tuple mentioned in
#1 also contains relatedTarget, but I neglected to mention this in the
spec. Filed https://www.w3.org/Bugs/Public/show_bug.cgi?id=20604.

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

Ah, wrong link. I meant steps 7 and 8 of
http://dom.spec.whatwg.org/#concept-event-dispatch, the AT_TARGET
steps.

>
>
>> 5) Finally, whenever adjusted relatedTarget and target are the same, skip
>> step 9.3 of http://dom.spec.whatwg.org/#dispatching-events. 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.
>
> How do you know at this point what the adjusted relatedTarget is if
> you change it at invoke as you said above?

See above.

:DG<