Re: [whatwg] seamless iframes and event propagation

On Mon, Dec 17, 2012 at 10:48 PM, Dimitri Glazkov <dglazkov@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>?


> 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.


> 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?


-- 
http://annevankesteren.nl/

Received on Tuesday, 8 January 2013 14:27:30 UTC