Bugzilla

[`PointerEvent.pointerId` is defined](https://w3c.github.io/pointerevents/#dom-pointerevent-pointerid) 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](https://searchfox.org/mozilla-central/rev/79f37e7fcd8994d86b0c610a87af4ef0343166ee/widget/MouseEvents.h#54), [`1` for pen on GTK](https://searchfox.org/mozilla-central/rev/79f37e7fcd8994d86b0c610a87af4ef0343166ee/widget/gtk/nsWindow.cpp#818), [native `pointerId` for touch on Android](https://searchfox.org/mozilla-central/rev/79f37e7fcd8994d86b0c610a87af4ef0343166ee/mobile/android/geckoview/src/main/java/org/mozilla/geckoview/PanZoomController.java#817) and also [native `pointerId` for touch on Windows](https://searchfox.org/mozilla-central/rev/79f37e7fcd8994d86b0c610a87af4ef0343166ee/widget/windows/nsWindow.cpp#4235-4236).

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](https://source.chromium.org/chromium/chromium/src/+/main:third_party/blink/renderer/core/events/pointer_event_factory.cc;l=240;drc=f83b758b5980e3fb3eafa11bab38116206907459) (according to the comment, it was compatible with EdgeHTML) and [`2`](https://source.chromium.org/chromium/chromium/src/+/main:third_party/blink/renderer/core/events/pointer_event_factory.cc;l=572;drc=2017cd8a8925f180257662f78eaf9eb93e8e394d) or [more](https://source.chromium.org/chromium/chromium/src/+/main:third_party/blink/renderer/core/events/pointer_event_factory.cc;l=787;drc=2017cd8a8925f180257662f78eaf9eb93e8e394d) 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.

```js
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 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).

[`PointerEvent.pointerId` is defined](https://w3c.github.io/pointerevents/#dom-pointerevent-pointerid) 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](https://searchfox.org/mozilla-central/rev/79f37e7fcd8994d86b0c610a87af4ef0343166ee/widget/MouseEvents.h#54), [`1` for pen on GTK](https://searchfox.org/mozilla-central/rev/79f37e7fcd8994d86b0c610a87af4ef0343166ee/widget/gtk/nsWindow.cpp#818), [native `pointerId` for touch on Android](https://searchfox.org/mozilla-central/rev/79f37e7fcd8994d86b0c610a87af4ef0343166ee/mobile/android/geckoview/src/main/java/org/mozilla/geckoview/PanZoomController.java#817) and also [native `pointerId` for touch on Windows](https://searchfox.org/mozilla-central/rev/79f37e7fcd8994d86b0c610a87af4ef0343166ee/widget/windows/nsWindow.cpp#4235-4236).

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](https://source.chromium.org/chromium/chromium/src/+/main:third_party/blink/renderer/core/events/pointer_event_factory.cc;l=240;drc=f83b758b5980e3fb3eafa11bab38116206907459) (according to the comment, it was compatible with EdgeHTML) and [`2`](https://source.chromium.org/chromium/chromium/src/+/main:third_party/blink/renderer/core/events/pointer_event_factory.cc;l=572;drc=2017cd8a8925f180257662f78eaf9eb93e8e394d) or [more](https://source.chromium.org/chromium/chromium/src/+/main:third_party/blink/renderer/core/events/pointer_event_factory.cc;l=787;drc=2017cd8a8925f180257662f78eaf9eb93e8e394d) 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.

```js
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).