releasePointerCapture firing InvalidPointerId when it shouldn't?

[patrickhlauke]

Not sure if it's my (admittedly horrible) code, but: see https://jsfiddle.net/dbjvwcz1/ in Edge and then in, say, Chrome. despite e.pointerId being correct (the same as when setPointerCapture was called), releasePointerCapture throws Uncaught Error: InvalidPointerId

(I see that simply omitting the releasePointerCapture in my hacky code actually makes it work just fine, and is ok as per spec since the UA should automatically release any captured pointers anyway on pointerup/pointercancel ... but still, this does seem to point to some issue in the releasePointerCapture code)

[patrickhlauke]

Actually, embarassingly enough I think I just gave the answer as to why this is happening myself...I'm assuming by the time the handler for pointerup is being called, PEP already automagically released the capture, and then rightly signals that there's no capture associated with that particular pointerId (anymore). And/or Edge is either releasing it fractionally later, or somehow not throwing an error.

[scottgonzalez]

I assumed that was the behavior as well, but was going to check against the spec to see if we already have wording about the use of releasePointerCapture() inside pointerup. Essentially, one of the implementations has to be wrong and we should document which it is.

[thenickdude]

The spec draft at W3C says "iImmediately after firing the pointerup or pointercancel events, a user agent must run the steps as if the releasePointerCapture() method has been called with an argument equal to the pointerId property of the pointerup or pointercancel event just dispatched."

https://w3c.github.io/pointerevents/#implicit-release-of-pointer-capture

And about releasePointerCapture(): "if the pointerId provided as the method's argument does not match any of the active pointers and these steps are not being invoked as a result of the implicit release of pointer capture, then throw a DOMException with the name InvalidPointerId."

So from what I can see, an exception should not be thrown in this case.

[thenickdude]

releasePointerCapture() requires:

If the pointerId provided as the method's argument does not match any of the active pointers [...] then throw a DOMException with the name InvalidPointerId.

In capture.js this is ensured by calling assertDown():

r = function releasePointerCapture(pointerId) {
  assertDown(pointerId);
  dispatcher.releaseCapture(pointerId, this);
};

The spec says of an active pointer:

If it is possible for a given pointer (identified by a unique pointerId) to produce additional events within the document, then that pointer is still considered active

So a mouse pointer should probably still be considered "active" after the button is released.

But in mouse.js, cleanupMouse() is called once all the mouse buttons have been released, just prior to the pointerup event being delivered. This deletes the pointer from the pointerMap, invalidating the pointer id. That causes assertDown() to fail, because the pointer doesn't exist, and so releasePointerCapture() called from the pointerup handler throws InvalidPointerId as a result.

It seems to me that cleanupMouse() should never be called? That way, the pointer ID would remain valid and releasePointerCapture() could validate the provided pointer ID against it.

[bethge]

@thenickdude sounds correct to me.

The spec actually directly mentions mouse input, so all good from that front.

A mouse connected to the device is always active.

Currently pointermap in mouse.js is also used to detect if any button is pressed - that should be a simple fix.
I believe any mouse event would need to check with the pointermap, be it just the initial registration of the mouse as an active pointer.

This looks like it would resolve the initial issue by @patrickhlauke for mouse pointer which are always active. The timing issue would still exist for touch pointers, since touch pointers are only active while there is a touch contact.

[scottgonzalez]

The other thing we need to handle is calling setPointerCapture() on a mouse when no buttons are being pressed. This should not throw an error because the pointer is active, but it should also not actually set capture since the pointer is not in an active buttons state.