Clarify whether touch contact must fire a pointerrawupdate event

[yacinehmito]

In the current draft, one can read the following in paragraph 4.2.5:

A user agent MUST fire a pointer event named pointerrawupdate only within a secure context when a pointing device attribute (i.e. button state, coordinates, pressure, tangential pressure, tilt, twist, or contact geometry) is changed.

Consequently, a touch contact, which affects button state, must fire a pointerrawupdate event.

However:

• pointerrawupdate is frequently compared to pointermove across the document, which does not fire on touch contact.
• On Blink, which has implemented the Level 3 of the specification, touch contact does not fire any pointerrawupdate events.

Was it intended to communicate a requirement to fire pointerrawupdae on button state change?

[yacinehmito]

Paging @NavidZ, author of the paragraph.

[NavidZ]

@yacinehmito good question. Let's be on the same page on a few things first:

• In PE spec we do fire pointermoves when button state changes only in chorded button interactions case. Hopefully all browsers are implementing this as this is specified.
• Chromium right now only raf-aligns pointermove (i.e. delays and batches them and fires one right before raf callback) and does not raf-align pointerdown and pointerup events (i.e. it immediately fires down and up events). Maybe other browsers can chime in here for this behavior as well. The raf align definition itself is very loose and sort of up to the user agent and is being referenced very loosely in PE spec as well as I believe it should be defined in html spec or something.

Our original intention of pointerrawupdate was to disable this raf aligning behavior which was originally introduced to save main thread redundant work that was not needed in most cases.

In terms of consistenty I have no issue and cannot imagine a problem with sending pointerrawupdate for pointerdown and pointerup as well.

So two options here:

• Either change the spec to specify pointerrawupdate firing only for chorded-button-interactions (If only right now no implementation fires pointerrawupdate for pointerdown and pointerup events).
• Or change implementations to also fire pointerrawupdate for pointerdown and pointerup events as well which seems more consitent across the board.

I wonder what others think. @patrickhlauke @smaug---- @mustaqahmed @liviutinta

[patrickhlauke]

• In PE spec we do fire pointermoves when button state changes only in chorded button interactions case.

Not sure that's what this says https://w3c.github.io/pointerevents/#the-pointermove-event

A user agent MUST fire a pointer event named pointermove when a pointer changes button state. Additionally one pointermove MUST be fired when pointer changes coordinates, pressure, tangential pressure, tilt, twist, or contact geometry (e.g. width and height) and the circumstances produce no other pointer events defined in this specification.

i.e. it's saying "pointer changes button state", not limiting it to just chorded button interactions

and https://w3c.github.io/pointerevents/#dfn-chorded-button-interactions doesn't say anything about not firing any pointermove events, from what I can see.

unless i'm missing something somewhere non-obvious...

[patrickhlauke]

philosophically though https://w3c.github.io/pointerevents/#the-pointerrawupdate-event

A user agent MUST fire a pointer event named pointerrawupdate only within a secure context when a pointing device attribute (i.e. button state, coordinates, pressure, tangential pressure, tilt, twist, or contact geometry) is changed.

when a touch "appears" on a touchscreen the button state is not really changed, as the pointer only just appeared and wasn't there to begin with before the finger was on the touchscreen. so as a layperson, i wouldn't expect a pointerrawupdate event to be fired there as it's not a change as such, but an appearance of a new pointer that yes happens to have a particular button state. unless it's splitting hairs too much?

[NavidZ]

i.e. it's saying "pointer changes button state", not limiting it to just chorded button interactions

and https://w3c.github.io/pointerevents/#dfn-chorded-button-interactions doesn't say anything about not firing any pointermove events, from what I can see.

unless i'm missing something somewhere non-obvious...

I don't think you are missing anything. That's probably why pointerrawupdate description also states the same thing as I probably just copy pasted from pointermove description. But I know browsers today do not fire a pointermove for the first button depressed and the last button released and instead fire pointerdown and pointerup respectively.

when a touch "appears" on a touchscreen the button state is not really changed, as the pointer only just appeared and wasn't there to begin with before the finger was on the touchscreen. so as a layperson, i wouldn't expect a pointerrawupdate event to be fired there as it's not a change as such, but an appearance of a new pointer that yes happens to have a particular button state. unless it's splitting hairs too much?

That's also a fair interpretation that I didn't think of. If we go with this then indeed the current wording is fine and makes sense not to fire pointerrawupdate at all.

[patrickhlauke]

That's also a fair interpretation that I didn't think of

however, in the case of mouse, that'd still leave a hole there i think. admittedly, i've never played directly with pointerrawupdate myself ... i might need to make a little test case and see how browsers handle it at the moment, and if we can come up with some specific rationale/addition to the spec on this point.

[yacinehmito]

Thank you very much for the prompt answer.

when a touch "appears" on a touchscreen the button state is not really changed, as the pointer only just appeared and wasn't there to begin with before the finger was on the touchscreen. so as a layperson, i wouldn't expect a pointerrawupdate event to be fired there as it's not a change as such, but an appearance of a new pointer that yes happens to have a particular button state.

Good point.

Some more context as to why this is of interest to me:

At the moment, listening to pointerrawupdate events is the only way to implement touch behaviours on top of the default ones, controlled with touch-action. Say that I would like to determine the position of the pointer, while still allowing vertical scrolling. As the user starts scrolling up and down with their finger, an initial pointerdown and a few pointermove updates would fire, ended with a pointercancel event. However I discovered that on Chrome, pointerrawupdate are emitted continuously even when touch-action preserves pan-y.

Yet, there is no way to know when the finger is lifted from the digitizer, as neither pointerup nor pointerrawupdate fire when this happens. I therefore cannot implement the specific behaviour I am interested in (natural panning on overscrolling).

Our original intention of pointerrawupdate was to disable this raf aligning behavior which was originally introduced to save main thread redundant work that was not needed in most cases.

This sounds like I am not using pointerrawupdate for its intended purpose. Should the events then fire even when the default touch behaviour of the user agent takes over?

UPDATE: I just found out about issue #339.

[patrickhlauke]

yes, sounds like pointerrawupdate was/is being fired in Chrome when in theory it shouldn't ... it's certainly not documented behavior per spec

[smaug----]

Yeah, I was thinking the same. That sounds like a bug in Chrome.

[NavidZ]

Yeah I also agree that this seems to be a bug in Chrome. The idea of pointercancel was to stop the events in that stream no matter the event type. You seem to be relying on a behavior that is not spec'ed and is a quirk only in Chrome for your usecase. @liviutinta FYI

As you mentioned I don't think you are using pointerrawupdate for that. The intention of that event was solely performance and getting the events to the apps faster than they can render on the screen for say off-screen canvas drawing or cloud gaming that they send the events to the network and whatnot.

This sounds like I am not using pointerrawupdate for its intended purpose. Should the events then fire even when the default touch behaviour of the user agent takes over?

No. They shouldn't as per the current spec.

But going back to your use case, we have heard feedbacks for this usecase that people still wanting to react to the input while scrolling. Could you elaborate more on that to see what kind of interaction you want to implement during scroll that is not possible say with scroll-linked animations and whatever new features those folks are working towards these days?
edit: I just noticed you commented on the other issue about your use case which is great to keep them all together. Maybe we can discuss more there around that.

[patrickhlauke]

discussed in PEWG call today. issue closed as it relates to a bug in Chrome, and the additional use case is being discussed in #339 for possible future spec updates