24706 2014-02-18 01:28:27 +0000 Clarify when setPointerCapture is supposed to work 2014-03-04 01:06:05 +0000 1 1 1 Unclassified PointerEventsWG Pointer Events specification unspecified PC Linux RESOLVED FIXED P2 normal --- 1 bugs jrossi public-pointer-events public-pointer-events-bugzilla oldest_to_newest 100783 0 bugs 2014-02-18 01:28:27 +0000 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. 100784 1 jrossi 2014-02-18 01:33:42 +0000 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." 100785 2 bugs 2014-02-18 01:37:03 +0000 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. 100786 3 jrossi 2014-02-18 02:48:46 +0000 "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. 100797 4 bugs 2014-02-18 11:41:43 +0000 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. 100813 5 jrossi 2014-02-18 19:05:50 +0000 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. 101759 6 bugs 2014-03-03 16:54:51 +0000 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. 101804 7 jrossi 2014-03-04 01:06:05 +0000 Change made as discussed: https://dvcs.w3.org/hg/pointerevents/rev/747e4fe321d1