[whatwg] seamless iframes and event propagation
dglazkov at chromium.org
Tue Jan 8 09:32:20 PST 2013
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
>> and is actually a list of tuples, storing a relative target in addition to
> 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
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
>> 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
> 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
>> 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?
More information about the whatwg