"This API always returns at least one coalesced event for pointermove events and an empty list for other types of PointerEvents."

[smaug----]

So, if one creates new pointermove event using JS (but passes empty array as coalescedEvents), does getCoalescedEvents really return non-empty array?

Also, the spec contradicts itself.
"None of the events in the sequence will have (nested) coalesced events, so getCoalescedEvents returns an empty sequence for them."

So, empty sequence for the pointermove events in the list, but

"This API always returns at least one coalesced event for pointermove events and an empty list for other types of PointerEvents."

[smaug----]

@NavidZ right now it is rather impossible to follow the spec when trying to implement getCoalescedEvents. Any chance you could take a look at this?
How does this all work in Chrome currently?

[NavidZ]

Sorry for the delay. Apparently I missed this issue before.

So, if one creates new pointermove event using JS (but passes empty array as coalescedEvents), does getCoalescedEvents really return non-empty array?

Yes. They can also create a pointerdown event and pass a non-empty array as coalescedEvents and they will get the same array from that object. In general the constructor doesn't modify what is fed by the developer. Whatever guarantee you will see in the spec is for the trusted events. I believe that is the same pattern in other places as well. For example we said the pressure is 0 for pointerup events (in the original pointerevent spec). That doesn't mean one cannot create an un-trusted pointerup with non-zero pressure.

Also, the spec contradicts itself.
"None of the events in the sequence will have (nested) coalesced events, so getCoalescedEvents returns an empty sequence for them."

So, empty sequence for the pointermove events in the list, but

"This API always returns at least one coalesced event for pointermove events and an empty list for other types of PointerEvents."

I guess the above comment might address this too as that restriction is not for all pointermove ever generated. But I see your point as the coalesced events are also happen to be trusted. Would it be better to change the sentence to say:

None of the events in the sequence will have (nested) coalesced events, so getCoalescedEvents returns an empty sequence for them. This API always returns at least one coalesced event for dispatched pointermove events and an empty list for other types of PointerEvents.

Note that the coalesced events are never dispatched on their own.

[smaug----]

This API always returns at least one coalesced event for dispatched pointermove events and an empty list for other types of PointerEvents.

I don't understand this.
window.addEventListener("pointermove", function(e) { console.log(e.getCoalescedEvents()); } ); window.dispatchEvent(new PointerEvent("pointermove"));
prints empty list in Chrome.

[NavidZ]

You are firing an un-trusted event. When the spec talks about the guarantees it implies that they hold for the trusted events (fired by the browser). Does that make it better?
Instead of using window.dispatchEvent, move your mouse around so browser fires the events itself and you will see a non-empty list all the time.

[smaug----]

Yes, I know I'm firing un-trusted event, but the spec needs to be clear what happens when such event is fired. So yes, being explicit with when the array is guaranteed to be non-empty is needed in the spec.

[NavidZ]

I totally agree with you myself. So I can add a trusted restriction somewhere. But just to make sure we are on the same boat here. What do you think about guarantees in the other specs? For example this in the original PointerEvent spec:

Note: all pointerup events will have pressure 0.

Do you agree this and a lot of other instances fall into the same bucket and are inaccurate the same as this issue here? Because a non-trusted pointerup event can have a non-zero pressure or can be targeted to anything regardless of the capturing APIs.

[smaug----]

oh, it does fall into the same bucket yes. But somehow the issue was more visible in this extension spec text.

[patrickhlauke]

x-ref #223

discussed at PEWG meeting today. we'll bash out some proposed clarification in this issue.

[smaug----]

In the current spec it says "If this event is a pointermove or pointerrawupdate event, it is a sequence of all PointerEvent that were coalesced into this event; otherwise it is an empty list."
Perhaps that should be clarified apply to user agent created events only, so that JS created events just pass whatever was used when the event was constructed.
This is related to #223

[smaug----]

#391 fixed this