Intent to Ship: Change click, auxclick and contextmenu event types to PointerEvent

[Liviu Tinta]

Contact emails

liviu...@chromium.org, mus...@chromium.org, nzol...@chromium.org

Explainer

Make “click”, “contextmenu” and “auxlick” instances of PointerEvents (instead of MouseEvents), to allow web apps to identify the source of such events in a multi-pointer environment (with mouse, pen and multitouch capabilities), and utilize fractional coordinates.  No other aspect of these events or their dispatch mechanism would be changed.

(The “dblclick” event remains unchanged because it is considered a legacy event.)

Specification

The change proposed here covers three different specs which are in a “mixed” state now:

• The UI Events Spec defines “click” and “auxlick” as events of “Mouse Event Type” based on the PointerEvent interface (updated through this pull request).  This looks like a minor wording problem, modulo the fact that the definition should ideally reside in the PointerEvent spec.

• The HTML spec has a pending pull request blocked on compat study. See Compat Study and Risks sections below for more details.

• The PointerEvent spec has a pending pull request blocked on compat study.

• No spec defines the “contextmenu” event, and major browsers expose it as a MouseEvent (spec issue).

Summary

Change “click”, “contextmenu”, “auxlick” events to PointerEvent (instead of MouseEvent) to let developers: distinguish between mouse, pen and individual fingers in a multitouch interaction through pointerType and pointerId attributes, and utilize fractional event coordinates for high precision use cases.

There were concerns about compat implications of this change but our compat study (see below) does not support those concerns.

The “click” and “contextmenu” events were defined as MouseEvents decades ago when a mouse was the only source of pointer-like events.  The “auxclick” event was defined similarly only a few years ago.  The ability to distinguish these events by input source in a multi-pointer environment is a long-standing developer request (e.g. this MSDN request).  PointerEvents spec discussion reached consensus that it would be a useful change and also expressed compat concerns.

Compat study

To better understand compat implications, Chrome committed to experimenting in the wild. We made the change available as an experimental web-platform feature in Sep 2019, started a Finch experiment in Canary in Aug 2020, and gradually expanded the scope of the experiment to cover Canary, Dev and Beta by Nov 3rd 2020. We have been running weekly “bug hunting” sessions to spot any related bug report, so far didn’t find any.

Demo link

New event properties available now (pointerType, pointerId, fractional coordinates, etc) could be viewed through https://rbyers.github.io/eventTest.html or any event inspection tools (including DevTools).  Chrome needs to be started with the command-line switch --enable-blink-features=ClickPointerEvent

Blink component

Blink>Input

TAG review

The tag review process is being skipped because this change does not involve any design decision.

TAG review status

Not applicable

Risks

  Interoperability and Compatibility

The availability of new event attributes (pointerType, pointerId) in “click”,   “contextmenu” and “auxlick” won’t pose any compat risk.  For interop, any app that would rely on these PointerEvent attributes would work on an unsupported browser (where these events are MouseEvents) if the app remembers the corresponding attributes in the last “pointerdown” or “pointerup” event before the “click”/“contextmenu”/“auxlick” event.

There are compatibility concerns with switching the event coordinates to floating point numbers.  So far we know about a single case that Microsoft Edge faced many years ago with Microsoft Ajax framework; that particular repro works fine with Chrome changes.  We are not aware of any breakage caused by either our ongoing finch trial or our experimental feature status.

Gecko: Request for Position

WebKit: Request for Position

Web developers: No signals

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

Yes.

Is this feature fully tested by web-platform-tests?

Yes. 

pointerevents/pointerevent_click_is_a_pointerevent.html

pointerevents/pointerevent_auxclick_is_a_pointerevent.html

pointerevents/pointerevent_contextmenu_is_a_pointerevent.html

uievents/interface/click-event.htm

Tracking bug

https://crbug.com/989958

Link to entry on the Chrome Platform Status

https://www.chromestatus.com/feature/5670732015075328

This intent message was generated by Chrome Platform Status.

[Rick Byers]

LGTM1

I'm excited to see this happen! Early in PointerEvents we knew we should do this, but were scared off by the one compat issue Edge hit when they tried many years ago. Thank you for investing in studying the compat impact - it definitely seems like the risk is low enough that we should try going to 100% and just be prepared to back out if the compat impact is non-trivial.

Rick

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAHaAqYJdaq6SsmMNT3oDBqZGv_DgMh3x5yebJ-Ykyvvp4iF3tQ%40mail.gmail.com.

[Chris Harrelson]

LGTM2

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAFUtAY9gPm-N2bVj0FsSO6p7g%2BUmKf05FeQsO8cfF6iPJX5SJQ%40mail.gmail.com.

[Yoav Weiss]

LGTM3

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAOMQ%2Bw9UE75qVii5MiW9uRp6wmJO8Z34Rvsp%3Dr4O4ar4mMnFDw%40mail.gmail.com.

[Aaron Tagliaboschi]

Out of curiosity, is the extra information you get from PointerEvent (especially the pointerType) available from another interface? Non-standard pointers (especially on desktop) could be fairly revealing, fingerprinting-wise.

[Liviu Tinta]

 pointerId, pointerType are available through existing pointer events.

For purposes of populating pointerId, pointerType for click/auxclick/contextmenu we use the (already exposed) pointerId and pointerType of the pointer event stream that generates the click/auxclick/contextmenu event (see PointerEvent PR). If the click/auxclick/contextmenu event is not generated from a pointer event stream then we use the default values: 0 for pointerId and empty string for pointerType.

[Aaron Tagliaboschi]

I misunderstood the doc I was reading; I didn't realize there were already pointer* events and this just untifies those with the mouse* events. Nevermind then!

Aaron Tagliaboschi | Software Engineer, Chrome Trust & Safety

[Liviu Tinta]

Update: we've been running a Finch experiment for the last few months, slowly ramping it up and monitoring for bugs from the field. We've had 4 field bugs: crbug.com/1181048, crbug.com/1182909 , crbug.com/1192449, crbug.com/1192911. Two of the bugs, crbug.com/1192911 and crbug.com/1192449, were logged since March 23rd 2021 when we've ramped up the experiment to 50% Stable. 

The main concern developers have is with the change from integer coordinates to fractional coordinates for the click event. Developers are comparing for equality mousedown coordinates with click coordinates in order to differentiate between a click and a drag.

The developers affected implemented two different fixes:

• use Math.floor on click coordinates before testing for equality with mousedown coordinates
• relax the equality check to test if the distance between mousedown coordinates and click coordinates is less than a configured value ( we consider this approach superior to the one above )

We have the option to expose click/contextmenu/auxclick coordinates as integers while keeping click/contexmenu/auxclick as pointer events. This behaviour is implemented behind a flag so we could turn it on easily if fractional coordinates become a big problem.

Right now we plan to run the Finch experiment as is for another 3 weeks to see if there will be more bugs logged.

 

[Mustaq Ahmed]

An update on regressions with fractional coordinates in "click" events: in the last few weeks we encountered more reports that developers are facing challenges deploying our suggested workaround.  See crbug.com/1192449.  Yesterday we received this comment about the negative impact of this change on users of older releases of ESRI software and APIs.

We didn't receive any reports of problems with other aspects of the change (switching the "class" of the events, adding  new attributes like pointerId and pointerType).

So we decided to switch to our mitigation plan: we will ship the feature but without any change in coordinates. More precisely, click, auxclick and contextmenu events will be instances of PointerEvents but their coordinates will be integers like before (like MouseEvents).

We have reopened the spec issue to update relevant specs accordingly.  We are currently working on updating the Finch experiment in Chrome.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/f3cf21ba-c52b-466e-a975-11b96238d5f8n%40chromium.org.