-
Notifications
You must be signed in to change notification settings - Fork 24
'Retargeting steps' expose closed Shadow DOM to the outside world #92
Comments
I'm not quite sure what blink does here. I think it does retargeting before event propagation, but it creates clones of Touch objects with different target, and not just retarget them. My interpretation could be wrong. |
Yeah, this sounds a spec bug. Retargeting steps shouldn't happen while in event dispatching. It's too late. |
This should be probably fixed closer to the way relatedTarget is handled when creating the path. |
I'm happy to take PRs for faster algorithms if they do not end up being much more complicated. Clarity is still the number one concern. It seems this issue affects UI Events too, but the algorithm there hasn't been written yet: w3c/uievents#157? Will you work on this @hayatoito or should I take a look? Perhaps also track this on the whatwg/dom repository to make it easier for folks to contribute (we don't have to mention the specific case of touch events as this is more general than that I think)? |
Yeah, I don't care the performance of algorithms described in the standard. Blink had already implemented may of themt in a different way, with an equivalent visible behavior.
I don't care who will work on this. I would be happy if @annevk or @smaug---- could work on this. |
Need to also figure out what happens to targetTouches, since the number of objects in that list may change while crossing shadow boundary. |
@smaug---- i know this is ancient now, but as I just touched this (hah) for the first time in forever for #135 I'm wondering if this came to any kind of conclusion? |
This is similar to whatwg/dom#525 (comment)
None of the retargeting can happen during event propagation.
I think this is both DOM and Touch event spec bug.
'Retargeting steps' need to happen when we create the event path.
@annevk, @hayatoito
(Not sure if @rniwa can comment on this)
The text was updated successfully, but these errors were encountered: