[whatwg] seamless iframes and event propagation
Anne van Kesteren
annevk at annevk.nl
Tue Jan 8 06:26:59 PST 2013
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>?
> 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.
> 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?
> 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