Re: [whatwg] seamless iframes and event propagation

[Dimitri Glazkov]

On Fri, Jan 11, 2013 at 3:54 PM, Dimitri Glazkov  wrote:
> On Fri, Jan 11, 2013 at 11:56 AM, Anne van Kesteren  wrote:
>> I want you to create a list :-)

Apologies for such a long delay. Dog-ate-homework, etc. Here's what
WebKit does. If interface isn't mentioned, then there's nothing
special going on there.

Legend:
* N -- no change
* L -- computed lazily from target
* R - computed when retargeting
* X - influenced by shadow DOM changes in event dispatch process

Event:
type - N
target - R
currentTarget - R
eventPhase - X
bubbles - N
cancelable - N
timeStamp - N
defaultPrevented - N
srcElement == target - R
returnValue - N
cancelBubble - N
clipboardData - N

UIEvent:
view - N
detail - N
keyCode - N
charCode - N
layerX - L
layerY - L
pageX - N
pageY - N
which - N

MouseEvent:
screenX - N
screenY - N
clientX - N
clientY - N
x - N
y - N
offsetX - L
offsetY - L
ctrlKey - N
shiftKey - N
altKey - N
metaKey - N
button - N
relatedTarget - R
fromElement - L
toElement - L
dataTransfer - N

We currently don't seem to be doing anything with Touch events, but we
probably should.

Touch (proposed):
clientX  - N
clientY - N
screenX - N
screenY - N
pageX - N
pageY - N
target - R
identifier - N

:DG<

Re: [whatwg] seamless iframes and event propagation

[Dimitri Glazkov]

On Fri, Jan 11, 2013 at 11:56 AM, Anne van Kesteren  wrote:
> On Fri, Jan 11, 2013 at 8:31 PM, Dimitri Glazkov  
> wrote:
>> Sure. Where are you seeing this list being mentioned? In Shadow DOM
>> spec or in DOM Core spec? I am happy to help, just not sure what
>> exactly I need to be doing :)
>
> I want you to create a list :-)

Okay.

Re: [whatwg] seamless iframes and event propagation

[Anne van Kesteren]

On Fri, Jan 11, 2013 at 8:31 PM, Dimitri Glazkov  wrote:
> Sure. Where are you seeing this list being mentioned? In Shadow DOM
> spec or in DOM Core spec? I am happy to help, just not sure what
> exactly I need to be doing :)

I want you to create a list :-) Which attributes are initialized
versus which are computed on getting... E.g. in Gecko with a synthetic
MouseEvent layerX/layerY (their offsetX/offsetY variant) do not seem
to be computed on getting.

For Touch Events the situation seems even more complicated, with
Touch.target in particular.


-- 
http://annevankesteren.nl/

Re: [whatwg] seamless iframes and event propagation

[Dimitri Glazkov]

On Fri, Jan 11, 2013 at 11:28 AM, Anne van Kesteren  wrote:
> On Fri, Jan 11, 2013 at 8:16 PM, Dimitri Glazkov  
> wrote:
>> On Fri, Jan 11, 2013 at 11:12 AM, Anne van Kesteren  wrote:
>>> Is that the case for all non-target/relatedTarget attributes that need
>>> adjustment? That they do not actually need to be adjusted but are
>>> calculated on getting based on the target and its conditions at the
>>> time of getting? (E.g. for touch events, the new pointer events,
>>> anything else?)
>>
>> That's been our implementation experience. It's neat that properties
>> on event objects fall cleanly into two categories:
>>
>> 1) properties that inform the author about the actual event dispatch
>> process (target, relatedTarget)
>> 2) properties that inform the author about the specifics of the event.
>>
>> The #1 are the ones that need adjustment for encapsulation. The #2 are
>> the ones that can be either computed on demand or don't need
>> adjustment.
>
> I'd like to have the concrete list, because in the event model all
> attributes are initialized before the event is dispatched and they do
> not change. That's the way init*Event() and now event constructors
> work. offset* (and a few others on MouseEvent) might be special
> because they were added later on and were not really standardized (I
> made an attempt in CSSOM View for MouseEvent extensions but did not
> cover this peculiarity).

Sure. Where are you seeing this list being mentioned? In Shadow DOM
spec or in DOM Core spec? I am happy to help, just not sure what
exactly I need to be doing :)

:DG<

Re: [whatwg] seamless iframes and event propagation

[Anne van Kesteren]

On Fri, Jan 11, 2013 at 8:16 PM, Dimitri Glazkov  wrote:
> On Fri, Jan 11, 2013 at 11:12 AM, Anne van Kesteren  wrote:
>> Is that the case for all non-target/relatedTarget attributes that need
>> adjustment? That they do not actually need to be adjusted but are
>> calculated on getting based on the target and its conditions at the
>> time of getting? (E.g. for touch events, the new pointer events,
>> anything else?)
>
> That's been our implementation experience. It's neat that properties
> on event objects fall cleanly into two categories:
>
> 1) properties that inform the author about the actual event dispatch
> process (target, relatedTarget)
> 2) properties that inform the author about the specifics of the event.
>
> The #1 are the ones that need adjustment for encapsulation. The #2 are
> the ones that can be either computed on demand or don't need
> adjustment.

I'd like to have the concrete list, because in the event model all
attributes are initialized before the event is dispatched and they do
not change. That's the way init*Event() and now event constructors
work. offset* (and a few others on MouseEvent) might be special
because they were added later on and were not really standardized (I
made an attempt in CSSOM View for MouseEvent extensions but did not
cover this peculiarity).


-- 
http://annevankesteren.nl/

Re: [whatwg] seamless iframes and event propagation

[Dimitri Glazkov]

On Fri, Jan 11, 2013 at 11:14 AM, Anne van Kesteren  wrote:

>>> Normally with  being a child of  there would not be any
>>> adjustment.
>>
>> Yup. I don't understand whether you're just agreeing with me or disagreeing 
>> :)
>>
>> With shadow trees in place, we need to let them react to events
>> happening in nodes, distributed to insertion points.
>
> Is there any adjustment if offset* are computed on getting anyway?
> (Calling it adjustment if there's no actual adjustment (they're just
> relative to target) seems wrong.)

Whoops, sorry -- don't understand if we're talking about adjust
target/relativeTarget or offset* in the example. If the former, then
yes, it's really not any sort of adjustment. Just grab the current
value of target and compute on demand.

:DG<

Re: [whatwg] seamless iframes and event propagation

[Dimitri Glazkov]

On Fri, Jan 11, 2013 at 11:12 AM, Anne van Kesteren  wrote:
> On Fri, Jan 11, 2013 at 7:56 PM, Dimitri Glazkov  
> wrote:
>> Can you elaborate on this a bit more. Note, you don't need to compute
>> offsetX/Y until they are actually requested (which is what WebKit does
>> anyway).
>
> I see. That would change matters indeed.
>
> Is that the case for all non-target/relatedTarget attributes that need
> adjustment? That they do not actually need to be adjusted but are
> calculated on getting based on the target and its conditions at the
> time of getting? (E.g. for touch events, the new pointer events,
> anything else?)

That's been our implementation experience. It's neat that properties
on event objects fall cleanly into two categories:

1) properties that inform the author about the actual event dispatch
process (target, relatedTarget)
2) properties that inform the author about the specifics of the event.

The #1 are the ones that need adjustment for encapsulation. The #2 are
the ones that can be either computed on demand or don't need
adjustment.

:DG<

Re: [whatwg] seamless iframes and event propagation

[Anne van Kesteren]

On Fri, Jan 11, 2013 at 7:56 PM, Dimitri Glazkov  wrote:
> On Fri, Jan 11, 2013 at 10:10 AM, Anne van Kesteren  wrote:
>> On Fri, Jan 11, 2013 at 6:50 PM, Dimitri Glazkov  
>> wrote:
>>> Okay, so event path would be (in tree order):
>>>
>>>  -- [shadow root] -> .. ->  --  -- [shadow
>>> root] -> .. -> 
>>>
>>> In this case, the adjustment happens twice, at  and .
>>
>> Normally with  being a child of  there would not be any
>> adjustment.
>
> Yup. I don't understand whether you're just agreeing with me or disagreeing :)
>
> With shadow trees in place, we need to let them react to events
> happening in nodes, distributed to insertion points.

Is there any adjustment if offset* are computed on getting anyway?
(Calling it adjustment if there's no actual adjustment (they're just
relative to target) seems wrong.)


-- 
http://annevankesteren.nl/

Re: [whatwg] seamless iframes and event propagation

[Anne van Kesteren]

On Fri, Jan 11, 2013 at 7:56 PM, Dimitri Glazkov  wrote:
> Can you elaborate on this a bit more. Note, you don't need to compute
> offsetX/Y until they are actually requested (which is what WebKit does
> anyway).

I see. That would change matters indeed.

Is that the case for all non-target/relatedTarget attributes that need
adjustment? That they do not actually need to be adjusted but are
calculated on getting based on the target and its conditions at the
time of getting? (E.g. for touch events, the new pointer events,
anything else?)

To nail this down we should more carefully define how those events are
dispatched. Which attributes are initialized and which are computed on
getting.


-- 
http://annevankesteren.nl/

Re: [whatwg] seamless iframes and event propagation

[Dimitri Glazkov]

On Fri, Jan 11, 2013 at 10:10 AM, Anne van Kesteren  wrote:
> On Fri, Jan 11, 2013 at 6:50 PM, Dimitri Glazkov  
> wrote:
>> On Wed, Jan 9, 2013 at 1:42 PM, Anne van Kesteren  wrote:
>>> My bad, I actually meant if 's associated shadow tree had an
>>> insertion point through which 's child, which is , would go and
>>> then the event would be dispatched in '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):
>>
>>  -- [shadow root] -> .. ->  --  -- [shadow
>> root] -> .. -> 
>>
>> In this case, the adjustment happens twice, at  and .
>
> Normally with  being a child of  there would not be any
> adjustment.

Yup. I don't understand whether you're just agreeing with me or disagreeing :)

With shadow trees in place, we need to let them react to events
happening in nodes, distributed to insertion points.

> If as you say offsetX/offsetY would be computed at invoke
> listener time, you just created an observable effect of implementing
> something in terms of shadow trees. (Which might not even be
> web-compatible.)

Can you elaborate on this a bit more. Note, you don't need to compute
offsetX/Y until they are actually requested (which is what WebKit does
anyway).

> I'm not sure that's desirable or even possible.
>
> Also, computing anything but target/relatedTarget at a point target
> might not even be in the DOM anymore seems very weird and counter to
> how the event model has worked thus far.

I agree. That's not what I am proposing.

>> 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
>
> Note that IE did not have a capture phase back then. So just saying
> "stopping" makes some amount of sense. With a capture phase you need
> to do something else. (I filed a bug on this the other day.)

Okay.

:DG<

Re: [whatwg] seamless iframes and event propagation

[Anne van Kesteren]

On Fri, Jan 11, 2013 at 6:50 PM, Dimitri Glazkov  wrote:
> On Wed, Jan 9, 2013 at 1:42 PM, Anne van Kesteren  wrote:
>> My bad, I actually meant if 's associated shadow tree had an
>> insertion point through which 's child, which is , would go and
>> then the event would be dispatched in '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):
>
>  -- [shadow root] -> .. ->  --  -- [shadow
> root] -> .. -> 
>
> In this case, the adjustment happens twice, at  and .

Normally with  being a child of  there would not be any
adjustment. If as you say offsetX/offsetY would be computed at invoke
listener time, you just created an observable effect of implementing
something in terms of shadow trees. (Which might not even be
web-compatible.)

I'm not sure that's desirable or even possible.

Also, computing anything but target/relatedTarget at a point target
might not even be in the DOM anymore seems very weird and counter to
how the event model has worked thus far.


> 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

Note that IE did not have a capture phase back then. So just saying
"stopping" makes some amount of sense. With a capture phase you need
to do something else. (I filed a bug on this the other day.)


-- 
http://annevankesteren.nl/

Re: [whatwg] seamless iframes and event propagation

[Dimitri Glazkov]

On Wed, Jan 9, 2013 at 1:42 PM, Anne van Kesteren  wrote:
>
> My bad, I actually meant if 's associated shadow tree had an
> insertion point through which 's child, which is , would go and
> then the event would be dispatched in '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):

 -- [shadow root] -> .. ->  --  -- [shadow
root] -> .. -> 

In this case, the adjustment happens twice, at  and .

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

Re: [whatwg] seamless iframes and event propagation

[Anne van Kesteren]

On Tue, Jan 8, 2013 at 6:32 PM, Dimitri Glazkov  wrote:
> 1) For a tree  -- [shadow root] ->  -- [shadow root] -> 
> (where "->" denotes child-parent relationship and "--" denotes
> host-root relationship)
> 2) if an event is dispatched on 
> 3) where is the event target's adjusted?
>
> If that's the question, then it needs to be adjusted twice: at 
> (the adjusted target becomes ) and at  (the adjusted target
> becomes ).

My bad, I actually meant if 's associated shadow tree had an
insertion point through which 's child, which is , would go and
then the event would be dispatched in '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/

Re: [whatwg] seamless iframes and event propagation

[Dimitri Glazkov]

On Tue, Jan 8, 2013 at 6:26 AM, Anne van Kesteren  wrote:
> On Mon, Dec 17, 2012 at 10:48 PM, Dimitri Glazkov  
> 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  ->  ->  ->  and an
> event is dispatched in 's  event's target is only adjusted
> on  right? It does not need to be adjusted further for 's
>  or ?

Does  stand for the actual  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  -- [shadow root] ->  -- [shadow root] -> 
(where "->" denotes child-parent relationship and "--" denotes
host-root relationship)
2) if an event is dispatched on 
3) where is the event target's adjusted?

If that's the question, then it needs to be adjusted twice: at 
(the adjusted target becomes ) and at  (the adjusted target
becomes ).

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

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

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

See above.

:DG<

Re: [whatwg] seamless iframes and event propagation

[Anne van Kesteren]

On Mon, Dec 17, 2012 at 10:48 PM, Dimitri Glazkov  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  ->  ->  ->  and an
event is dispatched in 's  event's target is only adjusted
on  right? It does not need to be adjusted further for 's
 or ?


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

Re: [whatwg] seamless iframes and event propagation

[Dimitri Glazkov]

On Mon, Dec 17, 2012 at 1:48 PM, Dimitri Glazkov wrote:

5) Finally, whenever adjusted *relatedTarget* and *target* are the same,
> skip step 9.3 of http://dom.spec.whatwg.org/#concept-event-listener-invoke.
> 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.
>

Correction here: the link should point to
http://dom.spec.whatwg.org/#dispatching-events.


>
> I think that's it :)
>
> :DG<
>
>

Re: [whatwg] seamless iframes and event propagation

[Dimitri Glazkov]

On Fri, Dec 14, 2012 at 12:18 PM, Anne van Kesteren wrote:

What would help me is to better understand the requirements of the
> shadow DOM with respect to event dispatch. To calculate the dispatch
> tree, you're using the event type, right? Then at certain points
> you're also making modifications to the Event object being dispatched,
> correct? Is there anything else? I'd like to expose those as hooks
> from the dispatch algorithm, but I'd like to make sure I'm not missing
> anything.
>

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

2) When invoking event listeners (
http://dom.spec.whatwg.org/#concept-event-listener-invoke), on step 3, we
initialize event's *currentTarget* and *target* attributes to the *relative
target* for the *ancestor* on which the listeners are invoked (consulting
the list of tuples computed in item 1).

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
.

4) The step 7 of
http://dom.spec.whatwg.org/#concept-event-listener-invokemay actually
happen more than once, since
*relative target* and *ancestor* always equal each other whenever the node
is a shadow host.

5) Finally, whenever adjusted *relatedTarget* and *target* are the same,
skip step 9.3 of http://dom.spec.whatwg.org/#concept-event-listener-invoke.
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.

I think that's it :)

:DG<

Re: [whatwg] seamless iframes and event propagation

[Anne van Kesteren]

On Fri, Dec 7, 2012 at 6:38 PM, Dimitri Glazkov  wrote:
> On Fri, Dec 7, 2012 at 1:23 AM, Anne van Kesteren  wrote:
>> Well, eventually we might want to merge the whole DOM part of Shadow
>> DOM and DOM I think, but for now my proposition was that dispatch
>> calculates its tree in terms of asking for the event parent of a
>> certain even type from an object. Shadow DOM could use that concept to
>> define what the parent is. E.g. for a shadow root it would be the
>> associated element, or not if the event type is something you do not
>> want to leak, etc.
>
> I think that's cool. cc' me on bug/patch, I want to review it.
>
>> That way when specifications use the dispatch algorithm it
>> automatically makes sense in the Shadow DOM rather than that you have
>> to monkey-patch whatever Shadow DOM says on top of DOM, which is
>> rather bad way of writing specifications.
>
> Yay! Moar hooks!

What would help me is to better understand the requirements of the
shadow DOM with respect to event dispatch. To calculate the dispatch
tree, you're using the event type, right? Then at certain points
you're also making modifications to the Event object being dispatched,
correct? Is there anything else? I'd like to expose those as hooks
from the dispatch algorithm, but I'd like to make sure I'm not missing
anything.


-- 
http://annevankesteren.nl/

Re: [whatwg] seamless iframes and event propagation

[Dimitri Glazkov]

On Fri, Dec 7, 2012 at 1:23 AM, Anne van Kesteren  wrote:

> On Thu, Dec 6, 2012 at 6:42 PM, Dimitri Glazkov 
> wrote:
> > The basic idea here is that some events, when they are dispatched in a
> > shadow tree, are more likely implementation details that aren't useful
> > outside of this tree. For example, if an  with an image of a volume
> > control loads inside of a , the author of  definitely
> doesn't
> > want the corresponding "load" event to leak out.
> >
> > We could come up with some way to control this via a new API, but beware
> the
> > growl of complexity bear.
>
> It sounds though like you'd want a different approach to this. What if
> I have a  as my implementation detail?
>

Then you probably don't want the "load" events of  escaping out of
the shadow tree, just as the spec provides.

It's an interesting question, though. Along with "load", such
implementation detail may dispatch a whole bunch of other events (
http://www.whatwg.org/specs/web-apps/current-work/multipage/the-video-element.html#mediaevents
).

Most of these events--at least, following my reasoning--seem like they
should just be kept in the shadow tree.

I wonder if we would be better off reversing the condition and stopping ALL
events, except a set of events whose meaning stays clear after retargeting
(like "click").


> > This logic written down in great detail in Shadow DOM spec -- and tested
> in
> > an actual browser implementation. Would you consider transplanting it
> into
> > DOM dispatch?
>
> Well, eventually we might want to merge the whole DOM part of Shadow
> DOM and DOM I think, but for now my proposition was that dispatch
> calculates its tree in terms of asking for the event parent of a
> certain even type from an object. Shadow DOM could use that concept to
> define what the parent is. E.g. for a shadow root it would be the
> associated element, or not if the event type is something you do not
> want to leak, etc.
>

I think that's cool. cc' me on bug/patch, I want to review it.


>
> That way when specifications use the dispatch algorithm it
> automatically makes sense in the Shadow DOM rather than that you have
> to monkey-patch whatever Shadow DOM says on top of DOM, which is
> rather bad way of writing specifications.
>

Yay! Moar hooks!

:DG<

Re: [whatwg] seamless iframes and event propagation

[Anne van Kesteren]

On Thu, Dec 6, 2012 at 6:42 PM, Dimitri Glazkov  wrote:
> The basic idea here is that some events, when they are dispatched in a
> shadow tree, are more likely implementation details that aren't useful
> outside of this tree. For example, if an  with an image of a volume
> control loads inside of a , the author of  definitely doesn't
> want the corresponding "load" event to leak out.
>
> We could come up with some way to control this via a new API, but beware the
> growl of complexity bear.

It sounds though like you'd want a different approach to this. What if
I have a  as my implementation detail?


>> So what I want is to tie this into the DOM's dispatch algorithm. The
>> dispatch algorithm somehow needs to compute the ancestor chain and the
>> current plan to do that is to follow an "event parent" chain (each
>> EventTarget would have an "event parent" which is either null or some
>> other object). However, it seems that is not quite enough for shadow
>> DOM so instead we need to determine the "event parent" of an object
>> algorithmically. I think we want "event parent for /event type/". So
>> e.g. on ShadowRoot objects the "event parent for load" would be null,
>> whereas for unicorn it would be its host element.
>>
>> Does that make sense?
>
> This logic written down in great detail in Shadow DOM spec -- and tested in
> an actual browser implementation. Would you consider transplanting it into
> DOM dispatch?

Well, eventually we might want to merge the whole DOM part of Shadow
DOM and DOM I think, but for now my proposition was that dispatch
calculates its tree in terms of asking for the event parent of a
certain even type from an object. Shadow DOM could use that concept to
define what the parent is. E.g. for a shadow root it would be the
associated element, or not if the event type is something you do not
want to leak, etc.

That way when specifications use the dispatch algorithm it
automatically makes sense in the Shadow DOM rather than that you have
to monkey-patch whatever Shadow DOM says on top of DOM, which is
rather bad way of writing specifications.


-- 
http://annevankesteren.nl/

Re: [whatwg] seamless iframes and event propagation

[Dimitri Glazkov]

On Wed, Dec 5, 2012 at 9:48 AM, Anne van Kesteren  wrote:

> On Wed, Dec 5, 2012 at 4:38 PM, Dimitri Glazkov 
> wrote:
> > Yes, the intent is that in the the events from nodes, distributed to
> > insertion points should feel as if there wasn't any shadow tree around
> them.
>
> Right, but if  is inside the shadow tree (rather than distributed
> into it), you do not want its load/error events to leak? (Again, it
> would help if the principles behind those events were written down,
> e.g. soonish  will start dispatching progress events and who
> knows what it might dispatch in the future. That list does not address
>  either if the same would apply to that element.)
>

The basic idea here is that some events, when they are dispatched in a
shadow tree, are more likely implementation details that aren't useful
outside of this tree. For example, if an  with an image of a volume
control loads inside of a , the author of  definitely doesn't
want the corresponding "load" event to leak out.

We could come up with some way to control this via a new API, but beware
the growl of complexity bear.


>
> So what I want is to tie this into the DOM's dispatch algorithm. The
> dispatch algorithm somehow needs to compute the ancestor chain and the
> current plan to do that is to follow an "event parent" chain (each
> EventTarget would have an "event parent" which is either null or some
> other object). However, it seems that is not quite enough for shadow
> DOM so instead we need to determine the "event parent" of an object
> algorithmically. I think we want "event parent for /event type/". So
> e.g. on ShadowRoot objects the "event parent for load" would be null,
> whereas for unicorn it would be its host element.
>
> Does that make sense?
>

This logic written down in great detail in Shadow DOM spec -- and tested in
an actual browser implementation. Would you consider transplanting it into
DOM dispatch?



>
> Ian, for HTML that would allow easily dealing with the load exception
> on Window too.
>
>
> --
> http://annevankesteren.nl/
>

Re: [whatwg] seamless iframes and event propagation

[Ian Hickson]

On Wed, 5 Dec 2012, Anne van Kesteren wrote:
> 
> Ian, for HTML that would allow easily dealing with the load exception on 
> Window too.

The load exception is weirder than that. It's target is different than the 
element that ever gets the event. Unless you mean the other exception, in 
which case, possibly, yes.

-- 
Ian Hickson   U+1047E)\._.,--,'``.fL
http://ln.hixie.ch/   U+263A/,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

Re: [whatwg] seamless iframes and event propagation

[Anne van Kesteren]

On Wed, Dec 5, 2012 at 4:38 PM, Dimitri Glazkov  wrote:
> Yes, the intent is that in the the events from nodes, distributed to
> insertion points should feel as if there wasn't any shadow tree around them.

Right, but if  is inside the shadow tree (rather than distributed
into it), you do not want its load/error events to leak? (Again, it
would help if the principles behind those events were written down,
e.g. soonish  will start dispatching progress events and who
knows what it might dispatch in the future. That list does not address
 either if the same would apply to that element.)

So what I want is to tie this into the DOM's dispatch algorithm. The
dispatch algorithm somehow needs to compute the ancestor chain and the
current plan to do that is to follow an "event parent" chain (each
EventTarget would have an "event parent" which is either null or some
other object). However, it seems that is not quite enough for shadow
DOM so instead we need to determine the "event parent" of an object
algorithmically. I think we want "event parent for /event type/". So
e.g. on ShadowRoot objects the "event parent for load" would be null,
whereas for unicorn it would be its host element.

Does that make sense?

Ian, for HTML that would allow easily dealing with the load exception
on Window too.


-- 
http://annevankesteren.nl/

Re: [whatwg] seamless iframes and event propagation

[Dimitri Glazkov]

On Wed, Dec 5, 2012 at 3:49 AM, Anne van Kesteren  wrote:

> On Wed, Dec 5, 2012 at 12:37 PM, Hayato Ito  wrote:
> > Some kinds of events should be always stopped at the shadow boundaries.
> > See
> http://dvcs.w3.org/hg/webcomponents/raw-file/tip/spec/shadow/index.html#events-that-are-always-stopped
>
> It's not entirely clear to me what that means. If an  ends up
> interleaved in a shadow tree through a  element, surely the
> node tree ancestors of  should still get the load event? Does the
> shadow tree not want to know this too?
>

Yes, the intent is that in the the events from nodes, distributed to
insertion points should feel as if there wasn't any shadow tree around them:
https://www.w3.org/Bugs/Public/show_bug.cgi?id=20247


> Also, is input missing from that list? A short explanation along with
> that list would probably be good so we know what the criteria are.
>

Sure, https://www.w3.org/Bugs/Public/show_bug.cgi?id=20248. I can't
remember now why I left it out, but I'll find out.


>
>
> > The Shadow DOM spec does not require adjusting mouse coodinates. I
> > think every shadow trees in one document *share* the same x-y
> > coodinates.
>
> There are coordinates relative to the target though, see:
> http://dev.w3.org/csswg/cssom-view/#extensions-to-the-mouseevent-interface
>
> I suppose if you do not initialize those on the object but instead
> compute them on getting it might work without having to adjust
> matters.
>

Whoa, good catch. https://www.w3.org/Bugs/Public/show_bug.cgi?id=20249
We do indeed cache/reset this value when retargeting in WebKit, but this
still needs to be specified.


>
>
> > I don't have a clear idea about what should be cloned when crossing
> > boundaries. That's unclear for me.
>
> Okay, I guess that remains then.
>

For shadow DOM, we definitely don't need cloning. But it seems critical for
seamless iframes. Looking forward, when we do add "isolated" to shadow
trees, the shadow DOM will use this plumbing too.

:DG<

Re: [whatwg] seamless iframes and event propagation

[Anne van Kesteren]

On Wed, Dec 5, 2012 at 12:37 PM, Hayato Ito  wrote:
> Some kinds of events should be always stopped at the shadow boundaries.
> See 
> http://dvcs.w3.org/hg/webcomponents/raw-file/tip/spec/shadow/index.html#events-that-are-always-stopped

It's not entirely clear to me what that means. If an  ends up
interleaved in a shadow tree through a  element, surely the
node tree ancestors of  should still get the load event? Does the
shadow tree not want to know this too?

Also, is input missing from that list? A short explanation along with
that list would probably be good so we know what the criteria are.


> The Shadow DOM spec does not require adjusting mouse coodinates. I
> think every shadow trees in one document *share* the same x-y
> coodinates.

There are coordinates relative to the target though, see:
http://dev.w3.org/csswg/cssom-view/#extensions-to-the-mouseevent-interface

I suppose if you do not initialize those on the object but instead
compute them on getting it might work without having to adjust
matters.


> I don't have a clear idea about what should be cloned when crossing
> boundaries. That's unclear for me.

Okay, I guess that remains then.


-- 
http://annevankesteren.nl/

Re: [whatwg] seamless iframes and event propagation

[Hayato Ito]

On Wed, Dec 5, 2012 at 8:16 PM, Anne van Kesteren  wrote:
> On Wed, Dec 5, 2012 at 11:54 AM, Hayato Ito  wrote:
>> Shadow DOM's event retargeting in WebKit uses one Event object for
>> every shadow trees.
>> When crossing shadow boundaries, an Event object's target (or
>> relatedTarget) is set to the appropriate one, but the event object
>> itself is reused.
>
> Interesting. Does Shadow DOM have a concept of events that are private
> to the shadow tree or does everything leak?

Some kinds of events should be always stopped at the shadow boundaries.
See 
http://dvcs.w3.org/hg/webcomponents/raw-file/tip/spec/shadow/index.html#events-that-are-always-stopped

>
> Also, if you change the target you need to adjust mouse coordinates
> and such as well. How does that work?

The Shadow DOM spec does not require adjusting mouse coodinates. I
think every shadow trees in one document *share* the same x-y
coodinates.

> Does that also happens if I
> dispatch a synthetic event using dispatchEvent()?

That should happen for a synthetic event. I am working on that at
https://bugs.webkit.org/show_bug.cgi?id=102681.

>
> (Not having thought much about it this seems especially hairy for
> elements from the ordinary node tree that interleaved via a 
> element.)
>
> But if Shadow DOM shares the Event object we should probably introduce
> a flag (e.g. a reuse Event object flag) next to the cross-boundary
> event parent pointer.
>
>
>> There, I created an Event object per frame. You can see the design in
>> the ChangeLog of the patch. Please don't take it seriously. It should
>> be considered as just an experiment at this stage.
>> https://bugs.webkit.org/attachment.cgi?id=168866&action=review
>
> The design Ian and I thought out is the same as far as calculating the
> dispatch tree goes and the same as far as what the result would be of
> invoking preventDefault() and such.
>
> What seems different is that Ian and I envisioned this to work for all
> events. And what seems unclear is what if anything is different
> between the clones of the Event object.

I don't have a clear idea about what should be cloned when crossing
boundaries. That's unclear for me.


>
>
> --
> http://annevankesteren.nl/



-- 
Hayato

Re: [whatwg] seamless iframes and event propagation

[Anne van Kesteren]

On Wed, Dec 5, 2012 at 11:54 AM, Hayato Ito  wrote:
> Shadow DOM's event retargeting in WebKit uses one Event object for
> every shadow trees.
> When crossing shadow boundaries, an Event object's target (or
> relatedTarget) is set to the appropriate one, but the event object
> itself is reused.

Interesting. Does Shadow DOM have a concept of events that are private
to the shadow tree or does everything leak?

Also, if you change the target you need to adjust mouse coordinates
and such as well. How does that work? Does that also happens if I
dispatch a synthetic event using dispatchEvent()?

(Not having thought much about it this seems especially hairy for
elements from the ordinary node tree that interleaved via a 
element.)

But if Shadow DOM shares the Event object we should probably introduce
a flag (e.g. a reuse Event object flag) next to the cross-boundary
event parent pointer.


> There, I created an Event object per frame. You can see the design in
> the ChangeLog of the patch. Please don't take it seriously. It should
> be considered as just an experiment at this stage.
> https://bugs.webkit.org/attachment.cgi?id=168866&action=review

The design Ian and I thought out is the same as far as calculating the
dispatch tree goes and the same as far as what the result would be of
invoking preventDefault() and such.

What seems different is that Ian and I envisioned this to work for all
events. And what seems unclear is what if anything is different
between the clones of the Event object.


-- 
http://annevankesteren.nl/

Re: [whatwg] seamless iframes and event propagation

[Hayato Ito]

Shadow DOM's event retargeting in WebKit uses one Event object for
every shadow trees.
When crossing shadow boundaries, an Event object's target (or
relatedTarget) is set to the appropriate one, but the event object
itself is reused.

FYI.
I've tried to implement event retargeting for seamless iframes in
WebKit just for an experiment.
https://bugs.webkit.org/show_bug.cgi?id=91290

There, I created an Event object per frame. You can see the design in
the ChangeLog of the patch. Please don't take it seriously. It should
be considered as just an experiment at this stage.
https://bugs.webkit.org/attachment.cgi?id=168866&action=review



On Wed, Dec 5, 2012 at 6:46 PM, Anne van Kesteren  wrote:
> On Wed, Dec 5, 2012 at 1:02 AM, Ian Hickson  wrote:
>> I've done the HTML side of this (a paragraph), but the heavy lifting for
>> this will be in DOM. Anne and I spoke about this earlier in #whatwg if you
>> want to see the discussions. Some pointers to the logs can be found in the
>> relevant DOM bug:
>>
>>https://www.w3.org/Bugs/Public/show_bug.cgi?id=18780
>
> So reading this thread it seems not everyone is on the same page as to
> whether all events (including synthetic), or just some will go
> cross-boundary. Ian and I thus far have been discussing a model where
> all events would go across boundaries.
>
> What would also be useful to know for the new dispatch design is what
> exactly the Shadow DOM is going to do. Will there be an Event object
> per "tree" or one Event object for the interleaved tree? (I guess both
> designs can be made to work. Shadow DOM will just have to set event
> parent/cross-boundary event parent as appropriate.)
>
> And finally, how should I deal with the 'load' exception for Window?
> If this object is the event parent of a Document and the event type is
> load, do nothing?
>
>
> --
> http://annevankesteren.nl/



-- 
Hayato

Re: [whatwg] seamless iframes and event propagation

[Anne van Kesteren]

On Wed, Dec 5, 2012 at 1:02 AM, Ian Hickson  wrote:
> I've done the HTML side of this (a paragraph), but the heavy lifting for
> this will be in DOM. Anne and I spoke about this earlier in #whatwg if you
> want to see the discussions. Some pointers to the logs can be found in the
> relevant DOM bug:
>
>https://www.w3.org/Bugs/Public/show_bug.cgi?id=18780

So reading this thread it seems not everyone is on the same page as to
whether all events (including synthetic), or just some will go
cross-boundary. Ian and I thus far have been discussing a model where
all events would go across boundaries.

What would also be useful to know for the new dispatch design is what
exactly the Shadow DOM is going to do. Will there be an Event object
per "tree" or one Event object for the interleaved tree? (I guess both
designs can be made to work. Shadow DOM will just have to set event
parent/cross-boundary event parent as appropriate.)

And finally, how should I deal with the 'load' exception for Window?
If this object is the event parent of a Document and the event type is
load, do nothing?


-- 
http://annevankesteren.nl/

Re: [whatwg] seamless iframes and event propagation

[Ian Hickson]

On Mon, 9 Jul 2012, Ojan Vafai wrote:
>
> I'd like to see us add event propagation into the parent document for 
> seamless iframes, e.g. key and mouse events inside a seamless iframe 
> should be refired on the iframe element.

I've done the HTML side of this (a paragraph), but the heavy lifting for 
this will be in DOM. Anne and I spoke about this earlier in #whatwg if you 
want to see the discussions. Some pointers to the logs can be found in the 
relevant DOM bug:

   https://www.w3.org/Bugs/Public/show_bug.cgi?id=18780

I'll look into adding a flag to turn this on and off from inside the frame 
when I do the cross-origin seamless flags.

-- 
Ian Hickson   U+1047E)\._.,--,'``.fL
http://ln.hixie.ch/   U+263A/,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

Re: [whatwg] seamless iframes and event propagation

[Ojan Vafai]

On Tue, Jul 17, 2012 at 7:51 PM, Dimitri Glazkov wrote:

> An interesting quirk here is whether the full list of event ancestors
> should be computed ahead of time (per
> http://www.w3.org/TR/dom/#dispatching-events). If yes, then it's still
> just like retargeting, but with issuing a new event object at the iframe
> boundary. If no, then two separate dispatches will work as you describe.


That's a good point. I suppose it makes sense to pre-compute the full list
of ancestors to be consistent with other events.

Re: [whatwg] seamless iframes and event propagation

[Dimitri Glazkov]

An interesting quirk here is whether the full list of event ancestors
should be computed ahead of time (per
http://www.w3.org/TR/dom/#dispatching-events). If yes, then it's still just
like retargeting, but with issuing a new event object at the iframe
boundary. If no, then two separate dispatches will work as you describe.

:DG<

Re: [whatwg] seamless iframes and event propagation

[Erik Arvidsson]

On Tue, Jul 17, 2012 at 4:28 PM, Ojan Vafai  wrote:
> It's not clear to me if any events should be exempt from this. For example,
> should focuses/blurs that are entirely contained within the seamless iframe
> fire in the outer document? My intuition is no, but I could easily be
> swayed either way.

mouseover/out etc should not fire in the outer document if the mouse
is just moving inside the iframe. In other words there must never be a
case where target and relatedTarget are the same.

-- 
erik

Re: [whatwg] seamless iframes and event propagation

[Ojan Vafai]

On Mon, Jul 16, 2012 at 9:24 AM, Dimitri Glazkov wrote:

> On Sat, Jul 14, 2012 at 4:45 AM, Olli Pettay 
> wrote:
> >
> > On 07/14/2012 12:38 AM, Ojan Vafai wrote:
> >>
> >> It's been pointed out to me that what I'm asking for is essentially the
> >> same retargeting as we do for shadow DOMs in web components, where the
> >> iframe is the shadow host and the document is the shadow root. This
> covers
> >> all the details of what properties need to be updated when crossing the
> >> document boundary. The only addition on top of that is that we need to
> >> convert the coordinate space of mouse events appropriately when we cross
> >> the boundary.
> >
> >
> >
> > What, you'd propagate mouse events to parent doc but update coordinate
> related coordinates when
> > passing the doc boundary... that is odd.
> > Something in the original target document may keep a reference to the
> event and then suddenly during event dispatch the
> > coordinate values would change.
>
> We should probably recreate an event object at each seamless frame
> boundary.
>

As I look at the event retargetting spec more closely, I think it's dealing
with a different set of design constraints and the seamless iframe
retargeting could do something much simpler.

Here's how I picture it working:
1. Create an event in the outer document with the seamless iframe
as its target and mouse events in the outer document's coordinate space and
begin the capture phase.
2. When the capture phase is done, if stopPropagation was not called, fire
a new event in the inner document as normal.
3. Execute target phase in the outer document.
4. Execute the bubble phase in the outer document.

If preventDefault is called on either the outer document's event or the
inner document's event, then the default action of the event is prevented.

It's not clear to me if any events should be exempt from this. For example,
should focuses/blurs that are entirely contained within the seamless iframe
fire in the outer document? My intuition is no, but I could easily be
swayed either way.

Ojan

Re: [whatwg] seamless iframes and event propagation

[Dimitri Glazkov]

On Sat, Jul 14, 2012 at 4:45 AM, Olli Pettay  wrote:
>
> On 07/14/2012 12:38 AM, Ojan Vafai wrote:
>>
>> It's been pointed out to me that what I'm asking for is essentially the
>> same retargeting as we do for shadow DOMs in web components, where the
>> iframe is the shadow host and the document is the shadow root. This covers
>> all the details of what properties need to be updated when crossing the
>> document boundary. The only addition on top of that is that we need to
>> convert the coordinate space of mouse events appropriately when we cross
>> the boundary.
>
>
>
> What, you'd propagate mouse events to parent doc but update coordinate 
> related coordinates when
> passing the doc boundary... that is odd.
> Something in the original target document may keep a reference to the event 
> and then suddenly during event dispatch the
> coordinate values would change.

We should probably recreate an event object at each seamless frame boundary.

:DG<

Re: [whatwg] seamless iframes and event propagation

[Olli Pettay]

On 07/14/2012 12:38 AM, Ojan Vafai wrote:

It's been pointed out to me that what I'm asking for is essentially the
same retargeting as we do for shadow DOMs in web components, where the
iframe is the shadow host and the document is the shadow root. This covers
all the details of what properties need to be updated when crossing the
document boundary. The only addition on top of that is that we need to
convert the coordinate space of mouse events appropriately when we cross
the boundary.



What, you'd propagate mouse events to parent doc but update coordinate related 
coordinates when
passing the doc boundary... that is odd.
Something in the original target document may keep a reference to the event and 
then suddenly during event dispatch the
coordinate values would change.


-Olli



http://dvcs.w3.org/hg/webcomponents/raw-file/tip/spec/shadow/index.html#event-retargeting

Ojan


On Mon, Jul 9, 2012 at 4:26 PM, Ojan Vafai  wrote:


I'd like to see us add event propagation into the parent document for
seamless iframes, e.g. key and mouse events inside a seamless iframe should
be refired on the iframe element.

Use-case 1: A global key event handler for keyboard shortcuts. Without
propagating the events, you need to add a key handler to each seamless
iframe's root in order for these keyboard handlers to work when the iframe
has focus.

Use-case 2: A dragging UI. Without event propagation, if you don't add
handlers to the iframe's root, you would just stop dragging when the mouse
is over seamless iframes. In addition, the coordinates of the mouse event
should be changed to the parent document's coordinate space when it is
refired on the iframe, otherwise your code needs to know when it's over an
iframe.

We should fire two events. One inside the iframe and one on the iframe
element itself (in the parent document). Any pointers to DOM nodes in the
event would need to be nulled out in the event fired in the parent document
if the seamless iframe is cross-domain and non-CORS accessible.

This makes seamless iframes more seamless. Most existing keyboard shortcut
and dragging JS code would magically keep working without needing to know
anything about seamless.

Use-case 3: Making an email client that wants the content of the email
isolated from the client's UI, but doesn't want a nested scrollbar (i.e.
the editable area sizes to the emails size). In this case, you don't want
to inherit the CSS for the mail client into the email's content. Similarly,
you may not want your global keyboard handlers to run when typing in the
editable area.

Similar to Adam's allow-seamless proposal, I'd like to see seamless have
the ability to tweak which bits of the frame act seamlessly. Adam's
proposal has inherit-styles. We could also add propagates-events to
allow-seamless. Both of those would be off by default. For seamless, we
could have no-inherit-styles and no-propagate-events in order to disable
either behavior, also off by default.

Ojan

On Sat, May 26, 2012 at 5:16 PM, Adam Barth  wrote:


Hi whatwg,

I've added a proposal to the wiki
 about letting a document
indicate that it is willing to be displayed seamlessly with a
cross-origin parent.  This proposal is a refinement of the approach
previously discussed in this thread:
.

Let me know if you have any feedback.

Thanks!
Adam

Re: [whatwg] seamless iframes and event propagation

[Ojan Vafai]

It's been pointed out to me that what I'm asking for is essentially the
same retargeting as we do for shadow DOMs in web components, where the
iframe is the shadow host and the document is the shadow root. This covers
all the details of what properties need to be updated when crossing the
document boundary. The only addition on top of that is that we need to
convert the coordinate space of mouse events appropriately when we cross
the boundary.

http://dvcs.w3.org/hg/webcomponents/raw-file/tip/spec/shadow/index.html#event-retargeting

Ojan


On Mon, Jul 9, 2012 at 4:26 PM, Ojan Vafai  wrote:

> I'd like to see us add event propagation into the parent document for
> seamless iframes, e.g. key and mouse events inside a seamless iframe should
> be refired on the iframe element.
>
> Use-case 1: A global key event handler for keyboard shortcuts. Without
> propagating the events, you need to add a key handler to each seamless
> iframe's root in order for these keyboard handlers to work when the iframe
> has focus.
>
> Use-case 2: A dragging UI. Without event propagation, if you don't add
> handlers to the iframe's root, you would just stop dragging when the mouse
> is over seamless iframes. In addition, the coordinates of the mouse event
> should be changed to the parent document's coordinate space when it is
> refired on the iframe, otherwise your code needs to know when it's over an
> iframe.
>
> We should fire two events. One inside the iframe and one on the iframe
> element itself (in the parent document). Any pointers to DOM nodes in the
> event would need to be nulled out in the event fired in the parent document
> if the seamless iframe is cross-domain and non-CORS accessible.
>
> This makes seamless iframes more seamless. Most existing keyboard shortcut
> and dragging JS code would magically keep working without needing to know
> anything about seamless.
>
> Use-case 3: Making an email client that wants the content of the email
> isolated from the client's UI, but doesn't want a nested scrollbar (i.e.
> the editable area sizes to the emails size). In this case, you don't want
> to inherit the CSS for the mail client into the email's content. Similarly,
> you may not want your global keyboard handlers to run when typing in the
> editable area.
>
> Similar to Adam's allow-seamless proposal, I'd like to see seamless have
> the ability to tweak which bits of the frame act seamlessly. Adam's
> proposal has inherit-styles. We could also add propagates-events to
> allow-seamless. Both of those would be off by default. For seamless, we
> could have no-inherit-styles and no-propagate-events in order to disable
> either behavior, also off by default.
>
> Ojan
>
> On Sat, May 26, 2012 at 5:16 PM, Adam Barth  wrote:
>
>> Hi whatwg,
>>
>> I've added a proposal to the wiki
>>  about letting a document
>> indicate that it is willing to be displayed seamlessly with a
>> cross-origin parent.  This proposal is a refinement of the approach
>> previously discussed in this thread:
>> .
>>
>> Let me know if you have any feedback.
>>
>> Thanks!
>> Adam
>>
>
>

Re: [whatwg] seamless iframes and event propagation

[Ojan Vafai]

On Wed, Jul 11, 2012 at 3:38 AM, Chaals McCathieNevile wrote:

> On Tue, 10 Jul 2012 01:26:13 +0200, Ojan Vafai  wrote:
>
>> Use-case 1: A global key event handler for keyboard shortcuts. Without
>> propagating the events, you need to add a key handler to each seamless
>> iframe's root in order for these keyboard handlers to work when the
>> iframe has focus.
>>
>
> Using javascript for keyboard shortcuts is not a good idea in the first
> place. People will keep doing it instead of something more scalable to the
> web like improving their accesskey implementations, but we should not be
> encouraging it, by making it easier to do the wrong thing instead of
> somethign useful.
>

In practice, this is a very common thing to do. Making seamless iframes not
work for this thing people are already doing seems backwards to me. We
should address the problems with why doing this in JS is problematic
directly.

(The problem is that javascript key handlers generally do not
> internationalise well, are awful across a wide range of devices, and are
> almost guaranteed to fail future devices).


How does accesskey improve on this?

 Use-case 2: A dragging UI. Without event propagation, if you don't add
>> handlers to the iframe's root, you would just stop dragging when the
>> mouse is over seamless iframes. In addition, the coordinates of the mouse
>> event should be changed to the parent document's coordinate space when it
>> is refired on the iframe, otherwise your code needs to know when it's
>> over an iframe.
>>
>
> Isn't this why we introduced native drag and drop to HTML?
>

This isn't about drag-dropping. It's about dragging within a web page (e.g.
a dialog). Again, there's a ton of code out there that does this. Making it
all retrofit to understand seamless seems like a non-starter to me. So, in
practice, any site that uses code like this and starts using seamless
iframes will have a crappy user experience.


> cheers
>
> Chaals
>
>  We should fire two events. One inside the iframe and one on the iframe
>> element itself (in the parent document). Any pointers to DOM nodes in the
>> event would need to be nulled out in the event fired in the parent
>> document if the seamless iframe is cross-domain and non-CORS accessible.
>>
>> This makes seamless iframes more seamless. Most existing keyboard
>> shortcut and dragging JS code would magically keep working without needing
>> to know anything about seamless.
>>
>> Use-case 3: Making an email client that wants the content of the email
>> isolated from the client's UI, but doesn't want a nested scrollbar (i.e.
>> the editable area sizes to the emails size). In this case, you don't want
>> to inherit the CSS for the mail client into the email's content.
>> Similarly, you may not want your global keyboard handlers to run when
>> typing in the editable area.
>>
>> Similar to Adam's allow-seamless proposal, I'd like to see seamless have
>> the ability to tweak which bits of the frame act seamlessly. Adam's
>> proposal has inherit-styles. We could also add propagates-events to
>> allow-seamless. Both of those would be off by default. For seamless, we
>> could have no-inherit-styles and no-propagate-events in order to disable
>> either behavior, also off by default.
>>
>> Ojan
>>
>> On Sat, May 26, 2012 at 5:16 PM, Adam Barth  wrote:
>>
>>  Hi whatwg,
>>>
>>> I've added a proposal to the wiki
>>> >
>>> about letting a document
>>> indicate that it is willing to be displayed seamlessly with a
>>> cross-origin parent.  This proposal is a refinement of the approach
>>> previously discussed in this thread:
>>> >> iframe-td33677754.html
>>> >.
>>>
>>> Let me know if you have any feedback.
>>>
>>> Thanks!
>>> Adam
>>>
>>>
>
> --
> Chaals - standards declaimer
>

Re: [whatwg] seamless iframes and event propagation

[Chaals McCathieNevile]

On Tue, 10 Jul 2012 01:26:13 +0200, Ojan Vafai  wrote:


I'd like to see us add event propagation into the parent document for
seamless iframes, e.g. key and mouse events inside a seamless iframe  
should be refired on the iframe element.


The first two of these use cases make no sense to me (which might just be  
because I am not very bright, or missing something...)



Use-case 1: A global key event handler for keyboard shortcuts. Without
propagating the events, you need to add a key handler to each seamless
iframe's root in order for these keyboard handlers to work when the  
iframe has focus.


Using javascript for keyboard shortcuts is not a good idea in the first
place. People will keep doing it instead of something more scalable to the
web like improving their accesskey implementations, but we should not be
encouraging it, by making it easier to do the wrong thing instead of
somethign useful.

(The problem is that javascript key handlers generally do not
internationalise well, are awful across a wide range of devices, and are
almost guaranteed to fail future devices).


Use-case 2: A dragging UI. Without event propagation, if you don't add
handlers to the iframe's root, you would just stop dragging when the  
mouse is over seamless iframes. In addition, the coordinates of the mouse

event should be changed to the parent document's coordinate space when it
is refired on the iframe, otherwise your code needs to know when it's  
over an iframe.


Isn't this why we introduced native drag and drop to HTML?

cheers

Chaals


We should fire two events. One inside the iframe and one on the iframe
element itself (in the parent document). Any pointers to DOM nodes in the
event would need to be nulled out in the event fired in the parent  
document if the seamless iframe is cross-domain and non-CORS accessible.


This makes seamless iframes more seamless. Most existing keyboard  
shortcut and dragging JS code would magically keep working without  
needing to know anything about seamless.


Use-case 3: Making an email client that wants the content of the email
isolated from the client's UI, but doesn't want a nested scrollbar (i.e.
the editable area sizes to the emails size). In this case, you don't want
to inherit the CSS for the mail client into the email's content.  
Similarly, you may not want your global keyboard handlers to run when

typing in the editable area.

Similar to Adam's allow-seamless proposal, I'd like to see seamless have
the ability to tweak which bits of the frame act seamlessly. Adam's
proposal has inherit-styles. We could also add propagates-events to
allow-seamless. Both of those would be off by default. For seamless, we
could have no-inherit-styles and no-propagate-events in order to disable
either behavior, also off by default.

Ojan

On Sat, May 26, 2012 at 5:16 PM, Adam Barth  wrote:


Hi whatwg,

I've added a proposal to the wiki
 about letting a document
indicate that it is willing to be displayed seamlessly with a
cross-origin parent.  This proposal is a refinement of the approach
previously discussed in this thread:
.

Let me know if you have any feedback.

Thanks!
Adam




--
Chaals - standards declaimer