Intent to Implement: Pointerrawmove

[Navid Zolghadr]

Contact emails
nzol...@chromium.org

Spec
https://github.com/w3c/pointerevents/pull/260

Spec issue: https://github.com/w3c/pointerevents/issues/214

Summary
Send pointerrawmove events for move events as soon as they happen as oppose to pointermove events which are being rAF-aligned and hence may add half a frame of latency on average from when they happened to when they are handled by javascript.

Motivation

We shipped rAF aligned input but there is a niche set of use cases that were missed in that proposal. In those scenarios developer does not necessary use the input to change DOM and whatnot. They might change the audio settings or something similar that aren’t tied to Chrome rendering a frame and with rAF aligned input in place Chrome potentially adds half a frame of latency on average to those events.

Interoperability risk
Firefox: No public signals
Edge: No public signals
Safari: No public signals
Web developers: No signals

Compatibility risk
There shouldn’t be any compatibility risk as this is going to be a new feature without modifying the existing behaviors.

Ongoing technical constraints
There are a few behaviors which we can choose differently with respect to this event type which are being discussed in the spec. But that is why the feature is going to be behind the flag for some developers to test and give us feedback.

Will this feature be supported on all six Blink platforms (Windows, Mac, Linux,
Chrome OS, Android, and Android WebView)?

Yes

OWP launch tracking bug
https://bugs.chromium.org/p/chromium/issues/detail?id=873684

Link to entry on the Chrome Platform Status
https://www.chromestatus.com/features/6041426311774208

Requesting approval to ship?

No. The feature will be implemented behind experimental-web-platform-features

[a...@google.com]

Have you considered the device fingerprinting aspect of providing the raw event? That is, could mice with different polling rates be distinguishable via this API because of the higher frequency of firing the event? If so, it might make sense to cap this to something that's equivalent to the polling rate of standard mice (which could still be faster than rAF, but would hide hardware-dependent details.)

Cheers,

-Artur

[Thiemo Nagel]

Hey Navid,

could you please file a launch bug and request a privacy review to discuss the fingerprinting aspects?

Thank you!

Thiemo

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/e07ec72f-6e17-4dc7-90d2-c1e783204e3f%40chromium.org.

Thiemo Nagel

Software Engineer

Google Germany GmbH, Erika-Mann-Straße 33, 80686 München

Geschäftsführer: Paul Manicle, Halimah DeLaine Prado

Registergericht und -nummer: Hamburg, HRB 86891

Sitz der Gesellschaft: Hamburg

[Thiemo Nagel]

(Or maybe just file a privacy review bug, whatever works best for you.)

[Navid Zolghadr]

Arthur, sorry I missed your email. You are correct. That is possible. But this is not something that this feature exposes to the web. It is already possible by looking at the getCoalescedEvents API of PointerEvents which we shipped before shipping rAF aligned input.

Thiemo, I have this bug up for the feature. I added the privacy review requirement to it. Let me know if I need to add additional labels to it.

Thanks,

Navid