Skip to content
This repository has been archived by the owner on Jul 9, 2024. It is now read-only.

'Retargeting steps' expose closed Shadow DOM to the outside world #92

Open
smaug---- opened this issue Jan 10, 2018 · 7 comments
Open

Comments

@smaug----
Copy link

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)

@smaug----
Copy link
Author

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.

@hayatoito
Copy link
Member

Yeah, this sounds a spec bug. Retargeting steps shouldn't happen while in event dispatching. It's too late.
We might want to fix this, as we did in whatwg/dom#525.

@smaug----
Copy link
Author

This should be probably fixed closer to the way relatedTarget is handled when creating the path.
The spec has of course very slow implementation of relatedTarget retargeting algorithm since it does it for every single event target, but still, I guess same could be done for Touch.target and then implementations optimize that.

@annevk
Copy link
Member

annevk commented Jan 11, 2018

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

@hayatoito
Copy link
Member

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.

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.

Will you work on this @hayatoito or should I take a look?

I don't care who will work on this. I would be happy if @annevk or @smaug---- could work on this.
If you couldn't and this is urgent, I might work on this in a few weeks.

@smaug----
Copy link
Author

Need to also figure out what happens to targetTouches, since the number of objects in that list may change while crossing shadow boundary.

@patrickhlauke
Copy link
Member

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

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants