offsetX/offsetY is confusing for GetCoalescedEvents

[RByers]

See this chromium bug and the definition of offsetX/offsetY.

Since an important use case of GetCoalescedEvents is to re-use (and share) existing code, perhaps we really should try harder to make these events look just like normal events? Eg. copy the target, and set the "dispatch flag" so that offsetX/offsetY get computed relative to the target?

[NavidZ]

That's correct. At the time we didn't have any use case in mind and we set the target to null to indicate we do not do hit-testing for those events. That bug seems a valid use case. Just one thing that we need to make sure it is clear that we don't hit-test those events. For example in that case offsetX/Y could be negative for those coalesced events as well which essentially means the events are outside of the target and could be unexpected for some apps.

[RByers]

Yep, I think that's the right trade-off. Some risk that the negative values could be confusing, but practically it should be very rare and fine when it occurs. Worst case and we see it cause confusion in the future, we could probably safely clamp to 0.

[wffurr]

I would fully expect negative offset values, especially when using the pointer capture feature to make sure I get the pointerup events to match the pointerdown events.

I was very surprised to find that the coalesced events didn't have the same target as the parent event.