Pointerevent extension

[NavidZ]

こんにちはTAG！

I'm requesting a TAG review of:

• Name: Pointerevents extension
• Specification URL: Pointerevents extension
• Explainer, Requirements Doc, or Example code: Example
• Tests: wpt/pointerevents/extension
• Primary contacts: @NavidZ @EiraGe

Further details (optional):

• Relevant time constraints or deadlines: None
• I have read and filled out the Self-Review Questionnare on Security and Privacy. The assessment is here.
• I have reviewed the TAG's API Design Principles

You should also know that...

[please tell us anything you think is relevant to this review]

We'd prefer the TAG provide feedback as (please select one):

• open issues in our Github repo for each point of feedback
• open a single issue in our Github repo for the entire review
• leave review feedback as a comment in this issue and @-notify [@NavidZ @EiraGe]

[slightlyoff]

Any updates?

[NavidZ]

@slightlyoff any updates on our side or the TAG folks?
I assume we provided all the information required. But let us know if there is anything missing.

[EiraGe]

Hi @alice, can we get an expedited review on this? We are waiting for the review to ship the predicted events api in chrome.

[annevk]

How does this feature interact with shadow trees?

What is the exact modification of the event dispatch algorithm required and where is the monkey patch specified?

The description of the two methods lacks the detail to lead to interoperable implementations around these questions, as far as I can tell.

[NavidZ]

@annevk can you explain a little more.
You mean how does the predicted points interact with the shadow trees? What does this have to do with that at all? GetPredictedPoints API doesn't change anything at all regarding the dispatch algorithm.

[annevk]

@NavidZ say the target node is inside a shadow tree. How is the target attribute of the events returned by these two new methods updated to ensure the shadow tree does not leak?

[NavidZ]

@annevk this spec does not specify when to set those targets. It just guarantees that they are the same as the event's target. It is up to UAs when to set them. For example in Chrome we have this lazy approach that we only set this when it is accessed. But regardless of that, the guarantee that the target of the events returned by these methods are the same as the target of the dispatched event should prevent that leak. WDYT?

[annevk]

You need to define the actual architecture that makes that work. E.g., define that these events hold a pointer to some parent and redefine the target attribute's getter so it can sometimes return the some parent's target instead. That will make it possible to verify that it's safe and will ensure that other extensions don't clash with it. The actual implementation can still be different from that, as long as it's black-box indistinguishable.

[NavidZ]

@annevk I haven't seen something like that around.
Would that be enough to just explain this logic in plain text in this spec? if not do you happen to have a similar example to this somewhere else so I can see what they did and use the same format?

[annevk]

I'm not sure what you mean. I'd expect this to require changes to the DOM Standard as well (e.g., you're proposing changes to Event's target attribute's getter).

It also seems this would potentially affect composedPath() in weird ways (or perhaps that's forwarded too?).

A similar thing is how Event objects have a relatedTarget internal slot that gets adjusted in various ways and other specifications defining subclasses of Event use to define some of their features.

[NavidZ]

FYI @smaug---- @patrickhlauke

The coalesced events or predicted events aren't really dispatched events. We wanted to avoid defining a new structure to avoid extra complexity. So we used the same event structure for simplicity and defined a bunch of attributes in this spec to be no-op (such as stopPropagation) or return default value.

But at the same time I don't want to just add all sort of hooks which makes the specification all more complex.
Do you think changing the type of these events to some other newly defined type is easier then than just adding all sort of hooks in the DOM spec? Obviously the new type will not have target or path() or composedPath or anything. Again the goal is to not over complicate this and add hooks in other specs that are only used by this single spec.

[annevk]

If these are only meant to carry some data using a dictionary would be a lot better, and likely easier, yes.

[NavidZ]

Yeah. Everything is just a value except offsetX/Y attributes which are calculated with respect to the target. So technically when the target of the dispatched event changes (like in shadow DOM cases) the offset of these coalesced/predicted points also needs to be recalculated with respect to the new target.

[annevk]

In that case it sounds like you still need some kind of more complicated setup. (But not that complicated. Objects have a pointer to the event and some of their getters do some calculations based on the Event's internal target slot.)

[smaug----]

I thought the idea was that one could handle coalesced events just like normal events, if needed, even if prototype was modified or so.
But then, yeah, path isn't useful there anyhow.

[alice]

Apologies for taking so long to get to this! We are in the process of trying to refine our processes to get quicker at working through our backlog, plus I missed the request to expedite.

Unfortunately I found this somewhat difficult to review. An explainer would help greatly - the spec has only minimal explanation of the problem these new APIs are intending to solve, which means I'm having to somewhat guess at the context, which also makes the review more time consuming for me.

In particular, I couldn't figure out from the spec what the purpose of getPredictedEvents() is; the introduction only mentions getCoalescedEvents(). When and why would I call this method? Are the predicted events computed on demand or are they pre-computed before the pointer event is fired? If the latter, is it possible to opt out to avoid unnecessary work being done? If the former, why is the browser better able to perform this computation than a javascript library, which has access to the same information via getCoalescedEvents()?

[NavidZ]

@alice I have updated the introduction to explain the later addition of predicted events and pointerrawupdate to the introduction as well. I also cleared up the getCoalescedEvents explanation as well. Sorry that the introduction was missed as that section is probably going to be removed/rewritten once merged to the pointerevents specification.

[slightlyoff]

the demo link is a 404; perhaps this is the right location?

https://eirage.github.io/Prediction/PredictionDemo.html

[EiraGe]

Yeah, sorry that I update the demo link recently....

[lknik]

Hi. Following a 12/06 telecon I filled a thing in your repo.

Furthermore, if you feel like there are no particular specific issues resulting fro this extension, perhaps at least link to considerations in the extended spec?

[patrickhlauke]

Thank you @lknik - we're hoping to merge the extension into what will become PE3 shortly, and will make sure to consider the implications for privacy/security of new features.

[lknik]

Sure. Any information about the plan for PE3 would be welcome, too. I still need to look at it all.
In the meantime, if this is meant to be a self-contained review, perhaps adding the consideretions in would be a good idea anyway?

[NavidZ]

We believe we addressed major concerns from TAG in the latest version. There is also a brief explainer for the features in the repository. Feel free to file more issues against the PointerEvent repo if you want clarification on more stuff.

[cynthia]

Thanks a lot! The explainer does make the intent and constraints a lot more clear. We'll hopefully discuss this in today's call.

[alice]

We discussed this in our telecon today and we're happy with the use case and the broad design here.

Happy to close this, but just some parting thoughts:

• We have some mild concern that the naming around getCoalescedEvents uses a word which is uncommon and difficult to spell, and is likely to be difficult for folks whose English vocabulary is not advanced for whatever reason. Something like getBundledEvents might be easier for more people to understand.

• The spec text seems a bit rough, with a lot of long, hard to read paragraphs and some ReSpec warnings, and the editors would presumably want to clean it up at some point. We mention this because it made the review more difficult, and presumably implementers would also find it difficult to digest.

Thank you for your patience through this review process, and for your hard work on this API.

[NavidZ]

Thanks @alice.

Regarding the ReSpec issues and everything editorial we are going to fix them all. As a matter of fact this extension document is going to go away and we are going to merge the content one at a time to the main spec and keep everything fixed with no warnings/errors.

Regarding the naming of it, just to give a little background Pointer Events working group actually had all different names including the one you suggested if I recall correctly. We intentionally said we need choose a hard word so people don't just randomly use it as it is a very niche API and hopefully that makes them go and look it up to see what it does and what "coalescing" means really. We knew most of the web apps should not care about or use these points for their use cases and using them would just hurt their performance and we were hoping this hard and more accurate word would serve that purpose as well.