1909803 - Should we align `PointerEvent.pointerId` values to Chrome?

Status: NEW

(Core :: DOM: Events, enhancement)

Description

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

PointerEvent.pointerId is defined as:

A unique identifier for the pointer causing the event. User agents MAY reserve a generic pointerId value of 0 or 1 for the primary mouse pointer. The pointerId value of -1 MUST be reserved and used to indicate events that were generated by something other than a pointing device. For any other pointers, user agents are free to implement different strategies and approaches in how they assign a pointerId value.
<snip>
The user agent MAY recycle previously retired values for pointerId from previous active pointers, or it MAY always reuse the same pointerId for a particular pointing device (for instance, to uniquely identify particular pen/stylus inputs from a specific user in a multi-user collaborative application).
<snip>

Currently, Gecko uses 0 for mouse events, 1 for pen on GTK, native pointerId for touch on Android and also native pointerId for touch on Windows.

According to the actual behavior, the pointerId for touch starts from 0 in the order of touches which gets activated. So, first touch is always 0.

On the other hand, Chromium uses 1 for mouse (according to the comment, it was compatible with EdgeHTML) and 2 or more for touch in (probably) per top-level browsing context.

The biggest difference between Gecko vs. Chromium is, the following code works (on Gecko) or does not work (on Chrome) as expected.

foo.addEventListener("mousedown", event => {
  event.target.setPointerCapture(event.pointerId);
});

MouseEvent.pointerId is always undefined. Therefore, it means a call of Element.setPointerCapture(0). Then, the pointerId matches with mouse and first touch (the only touch if a single tap). Therefore, we had bug 1907495, bug 1907494, bug 1907490 and bug 1907489.

So, we can guess that web app developers tries to capture a pointer with similar code, but Chrome worked without the API call but they don't test on Firefox, such apps may not work on Firefox.

I think that it's safer to align the pointerId value to Chromium's (but I guess it's not urgent).

Comment 1

[Kagami Rosylight [:saschanaz] (they/them)]

(In reply to Masayuki Nakano [:masayuki] (he/him)(JST, +0900) from comment #0)

Currently, Gecko uses 0 for mouse events, 1 for pen on GTK, native pointerId for touch on Android and also native pointerId for touch on Windows.

I think for Windows we use DispatchTouchInput for touch, not DispatchMouseEvent?

Safari on macOS also reports 0 for mouse, fwiw. (Interestingly Safari on iOS reports a huge number enough that it even overflows to a negative number 🤔)

Firefox on Android somehow uses 0 for touch too (and always resets to 0 when all touch points are removed), I guess the native Android pointerId for touch starts with 0?

Comment 2

[Dennis Schubert [:denschub]]

We found one site breakage for this, and imported it to Bugzilla as bug 1910415. It's not a high priority site, but given we know we differ from Chrome, we recommend experimenting with aligning our behavior here, and hoping that we don't break anything else. :)

Unsetting the webcompat-priority flag, as we can calculate the priority based on the linked site report.