This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
Currently it seems that one could use setPointerCapture for mouse pointer at any time. That would lead to various unexpected behaviors, like ads stealing pointers etc. I think mouse should be part of active pointers only between down and up.
This is already the case (and for the reasons you cite). From the steps in Section 10.1: "2.If the pointer is not in the active buttons state, then terminate these steps." The active buttons state is defined as: "The condition when a pointer has a non-zero value for the buttons property. For mouse, this is when the device has at least one button depressed. For touch, this is when there is physical contact with the digitizer. For pen, this is when the pen has physical contact with the digitizer."
setPointerCapture Sets pointer capture for the pointer identified by the argument pointerId to the element on which this method is invoked. Subsequent events for the pointer MUST always be targeted at this element. Throws a DOMException with the name InvalidPointerId when the provided the method's argument does not match any of the _active_pointers_. active pointer Any touch contact, pen stylus, mouse cursor, or other pointer that can produce events. If it is possible for a given pointer (identified by a unique pointerId) to produce additional events, then that pointer is still considered active. Examples: * _A_mouse_connected_to_the_device_is_always_active_. So the spec isn't consistent.
"active pointers" != "active button state" Hence, two separate entries in the glossary. active pointer - pointers that can still produce further events. pointer in the active button state - pointer with evt.buttons > 0. So the *exception throws* (step 1) when you're trying to set capture to a pointer that can't produce pointer events (e.g. a pointerId you made up or a pointerId for a pointer that has gone away like a finger that left the screen). The API *silently fails* (step 2) if you try to set it to a pointer that is just hovering.
I'm not talking about 10.1, but setPointerCapture description. It talks about active pointers, not active button state. 10.1 looks fine, it is https://dvcs.w3.org/hg/pointerevents/raw-file/tip/pointerEvents.html#widl-Element-setPointerCapture-void-long-pointerId which is misleading.
Ah, I think I understand. Would this description be better? "Sets pointer capture for the pointer identified by the argument pointerId to the element on which this method is invoked. Subsequent events for the pointer MUST always be targeted at this element. The pointer MUST be in its active buttons state for this method to be effective, otherwise it fails silently. Throws a DOMException with the name InvalidPointerId when the provided the method's argument does not match any of the active pointers." Feel free to propose alternate text.
Sounds good. Though, I wonder if non-active button state case should throw. Maybe not, since that would reveal to other domains whether mouse button is down.
Change made as discussed: https://dvcs.w3.org/hg/pointerevents/rev/747e4fe321d1