[whatwg] seamless iframes and event propagation

[Anne van Kesteren]

On Tue, Jan 8, 2013 at 6:32 PM, Dimitri Glazkov <dglazkov at chromium.org> wrote:
> 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>).

My bad, I actually meant if <a>'s associated shadow tree had an
insertion point through which <a>'s child, which is <b>, would go and
then the event would be dispatched in <b>'s associated shadow tree. (I
phrased that beyond poorly however and only tried to make up for it on
IRC.)


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

So why are offsetX and offsetY not calculated in advance? Those would
be affected by DOM manipulation in event listeners too. (If you have
all those attributes being different, would it not be easier to use a
different event object?)

Incidentally, was there any progress made on the magic list of events
that should not leak out of the upper boundary? If that list is based
on implementation experience of certain widgets in WebKit, maybe it
would be better if those widgets instead themselves took care of those
events not leaking through by having the appropriate event listeners?
Hmm, I guess that might not work for capturing... :/


-- 
http://annevankesteren.nl/