[whatwg] seamless iframes and event propagation

[Dimitri Glazkov]

On Wed, Jan 9, 2013 at 1:42 PM, Anne van Kesteren <annevk at annevk.nl> wrote:
>
> 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.)

Okay, so event path would be (in tree order):

<a> -- [shadow root] -> .. -> <insertion point> -- <b> -- [shadow
root] -> .. -> <c>

In this case, the adjustment happens twice, at <b> and <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.
>
> 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?)

I think it's okay if they are affected. They carry different type of
information and I would assume that the user wants to have the actual
position at the moment of running their event listener, rather than
some cached value.

> Incidentally, was there any progress made on the magic list of events
> that should not leak out of the upper boundary?

Not yet, still working on it here:
https://www.w3.org/Bugs/Public/show_bug.cgi?id=20247

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

As I mentioned before, it's not solely based on WebKit implementation
experience. Microsoft had a very similar list for viewlink and they
wanted me to look at it when I was working on this part of the spec:
https://www.w3.org/Bugs/Public/show_bug.cgi?id=15804

:DG<