+Windows -> Input

Oops, -Windows.

Hi brentons@: Although the visible cursor position on screen makes them feel like a single pointer, the spec definition says pointerId is unique for each active pointer:
https://w3c.github.io/pointerevents/#pointerevent-interface
So, from the perspective of PointerEvent.pointerId, this is WAI.

We agree the visible cursor needs to be fixed, what Edge on Windows does seems the best: remembering each pointer position individually, but never showing more than one of them. It would work only when both app & OS are aware of multi-pointers. This is the case with Edge plus Windows: Window's WM_POINTER API supports multi-pointers, and Edge uses the API, so it works as a whole. Chrome (still) doesn't use WM_POINTER API, instead uses a legacy mouse API, so Windows falls back to legacy single-pointer behavior for Chrome.  crbug.com/526153 .

Mac OS seems not ready for multi-pointers yet, at least that's what we see from Chrome: pointer-leave events from OS don't carry ids at all, which we guess is done to avoid problems with multi-pointers specifically.

I don't know about Linux, it may have the same problem.

If MacOS doesn't differentiate pointers well enough to drive separate cursors with them, the spec might need to change to reflect that.

What Chrome does on Windows (disable the trackpad while the stylus is sending events) seems like a reasonable compromise.  Of course, driving two independent cursors would be too.  However, the current behavior (emitting two different pointerIds for what's effectively one pointer) is certainly problematic.

FWIW, all pointerIds in Firefox on 0 on my Mac.  Unless we are supporting independent cursors, that seems like a better model.

Here's a more thorough test on Firefox.  They're mostly correct, except they get pointerType wrong for pens:

| Input (pointerdown)        | event.pointerType | event.buttons | event.pointerId | event.pressure |
| -------------------------- | ----------------- | ------------- | --------------- | -------------- |
| Wacom tap                  | mouse             | 1             | 0               | .5             |
| Wacom stylus tip           | mouse             | 1             | 0               | 0.352941185235 |
| Wacom stylus lower button  | mouse             | 2             | 0               | .5             |
| Wacom stylus upper button  | mouse             | 4             | 0               | .5             |
| Wacom stylus eraser        | mouse             | 1             | 0               | 0.572549045085 |
| MacBook one-finger click   | mouse             | 1             | 0               | .5             |
| MacBook two-finger click   | mouse             | 2             | 0               | .5             |

Mozilla pointerType bug reported: https://bugzilla.mozilla.org/show_bug.cgi?id=1304904

Thanks Brenton, we really appreciate your finding the issues as well as reaching out to FF.

I think from the spec perspective, the pointerId is associated to input, not to the visible cursor. Edge implementation made it unique per "input sequence" which is allowed in the spec. Then we followed Edge because the model seemed reasonable, and we have to maintain backward compatibility.

Associating pointerIds to "input sequences" seems reasonable for multipointers in particular: consider starting a two finger gesture on a multitouch screeen, and suppose that the pointerIds for those fingers are 10 & 11. Now release only one finger (say, the one with pointerId=11), and then touch the finger again. At this point, we have to used a different pointerId (say 12) for the new touch unless we know whether the new touch is the same finger used before (with pointerId=11) or a new finger. We can't (currently) identify individual physical fingers unless we can read the fingerprints :(

The same happens to stylus: suppose someone is drawing with two different stylus devices, one in each hand. If only one stylus is active at any given time, switching back & forth would have to keep using new pointerIds until we have an universal stylus device id of some sort.

Let's now consider associating pointerIds to "the visible cursor": first of all, a single visible cursor is an OS limitation which we hope will change---Windows has set a strong example here. Setting pointerId=const as a stop-gap measure could be a long-term headache for the web because some web developer could "overfit" their app to this behavior, making it harder to change the implementations in the future. Moreover, if a user is using two different input devices, say a mouse and a pen, the physical differences are more significant to the user than just the shared cursor IMO, so a shared id doesn't mean much here.

Regardless, the current situation (having independent pointerIds for codependent pointers) is problematic.  Thankfully, it's very much an edge case.

It seems like the solutions other browsers are taking (Edge disabling the trackpad while a stylus is hovering, or Firefox reporting the same pointerId for pointermove from either codependent cursor) are both reasonable, and both an improvement over what Chrome is currently doing.  We could also try to draw multiple cursors in Chrome until MacOS supports them natively, but that seems like a lot of effort, and a potentially confusing user experience.

I'm curious what kind of overfitting you imagine.  Either disabling a second pointer or collapsing the pointerIds of codependent pointers feel like better solutions than having two pointerIds both anchored to the same physical location.

This issue has been Available for over a year. If it's no longer important or seems unlikely to be fixed, please consider closing it out. If it is important, please re-triage the issue.

Sorry for the inconvenience if the bug really should have been left as Available. If you change it back, also remove the "Hotlist-Recharge-Cold" label.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

The FF pointerIds are not an example to follow here: it really looks like a lack of support for pointerIds.  There's a chance FF has realistic pointerIds now, didn't check though.

We have started using OS-level WM_POINTER in Windows (but only for stylus I believe), so chromium is getting better for sure.  We won't have the Edge-like behavior until all pointer-like input events are done through WM_POINTER.

Let's handle this bug through Issue 701357.