Oct 21, 2014: This document contains test assertions for the Pointer Events specification. These assertions helped guide the development of the Pointer Events Test Suite. The test suite is now considered sufficient to test the interoperability of the specification. As such, this document is no longer maintained. Please do not update this document. If you have any feedback, please send it to the public-pointer-events @ w3.org mail list (archive).
Test Assertions for Pointer Events
This page documents the test assertions for the Pointer Events specification [1].
Test Assertions for PointerEvent Interface
|
|
Assertion
|
Test Case
|
Status
|
| 1.1
|
For any PointerEvent object, each of the attributes must exist.
|
Approved
|
|
| 1.2
|
For any PointerEvent object, each of the attributes must be of the specified data type.
|
Approved
|
|
| 1.3
|
If a pointer event is initiated by a mouse device, then pointerType must be "mouse".
|
Approved
|
|
| 1.4
|
If a pointer event is initiated by a pen input device, then pointerType must be "pen".
|
Approved
|
|
| 1.5
|
If a pointer event is initiated by a touch input device, then pointerType must be "touch".
|
Approved
|
|
| 1.6
|
The value of pressure must be between 0 and 1 (inclusive).
|
Approved
|
|
| 1.7
|
If pointerType is "mouse" and buttons is 0, then pressure must be 0.
|
Approved
|
|
| 1.8
|
If pointerType is "mouse" and buttons > 0, then pressure must be 0.5.
|
Approved
|
|
| 1.9
|
If pointerType is "mouse", tiltX must be 0.
|
Approved
|
|
| 1.10
|
If pointerType is "mouse", tiltY must be 0.
|
Approved
|
|
| 1.11
|
If pointerType is "mouse", then pointerId must be 1.
|
NA
|
|
| 1.12
|
If pointerType is not "mouse", then pointerId must not be 1.
|
NA
|
|
| 1.13
|
If pointerType is "mouse", then isPrimary must be true.
|
Approved
|
|
Test Assertions for pointerdown events
|
|
Assertion
|
Test Case
|
Status
|
| 2.1
|
If the input device is a mouse and the device transitions from no buttons depressed to at least one button depressed, the pointerdown event must be dispatched.
|
Approved
|
|
| 2.2
|
If the input device is touch and the device makes physical contact with the digitizer, the pointerdown event must be dispatched.
|
Approved
|
|
| 2.3
|
If the input device is pen and the device makes physical contact with the digitizer, the pointerdown event must be dispatched.
|
Approved
|
|
| 2.4
|
For input devices that do not support hover, a pointerover event must precede the pointerdown event. Furthermore, the pointerType and isPrimary attributes of the pointerover event must be the same as the respective attributes of the corresponding pointerdown event.
|
Approved
|
|
| 2.4.1
|
For input devices that do not support hover, a pointerenter event must precede the pointerdown event. Furthermore, the pointerType and isPrimary attributes of the pointerenter event must be the same as the respective attributes of the corresponding pointerdown event.
|
Approved
|
|
| 2.x
|
If pointerType is "touch" and no other active pointers representing touch input exists, then isPrimary must be true.
|
NA
|
|
| 2.x
|
If pointerType is "touch" and some other active pointers representing touch input exist, then isPrimary must be false.
|
NA
|
|
| 2.x
|
If pointerType is "pen" and no other active pointers representing pen input exists, then isPrimary must be true.
|
NA
|
|
| 2.x
|
If pointerType is "pen" and some other active pointers representing pen input exist, then isPrimary must be false.
|
NA
|
|
Test Assertions for pointerup events
|
|
Assertion
|
Test Case
|
Status
|
| 3.1
|
The pointerType attribute of a pointerup event must have the same value as the pointerType attribute of the last pointerdown event with the same pointerId attribute.
|
Approved Test #1 & Test #2
|
|
| 3.2
|
The isPrimary attribute of a pointerup event must have the same value as the isPrimary attribute of the last pointerdown event with the same pointerId attribute.
|
Approved Test #1 & Test #2
|
|
| 3.3
|
If the input device is a mouse and the device transitions from at least one button depressed to no buttons depressed, the pointerup event must be dispatched .
|
Approved
|
|
| 3.4
|
If the input device is touch and physical contact is removed from the digitizer, the pointerup event must be dispatched.
|
Approved
|
|
| 3.5
|
If the input device is pen and the pen is removed from physical contact with the digitizer, the pointerup event must be dispatched.
|
Approved
|
|
| 3.6
|
For input devices that do not support hover, a pointerout event must follow the pointerup event. Furthermore, the pointerType and isPrimary attributes of the pointerout must be the same as the respective attributes of the corresponding pointerup event.
|
Approved
|
|
| 3.6.1
|
For input devices that do not support hover, a pointerleave event must follow the pointerup event. Furthermore, the pointerType and isPrimary attributes of the pointerleave must be the same as the respective attributes of the corresponding pointerup event.
|
Approved
|
|
| 3.7
|
If the setPointerCapture method has been invoked on the pointer specified by pointerId, and the releasePointerCapture method has not been invoked, a lostpointercapture event must be dispatched to the element on which the setPointerCapture method was invoked. Furthermore, subsequent events for the specified pointer must follow normal hit testing mechanisms for determining the event target.
|
Approved
|
|
Test Assertions for pointercancel events
|
|
Assertion
|
Test Case
|
Status
|
| 4.1
|
The pointerType attribute of a pointercancel event must have the same value as the pointerType attribute of the last pointerdown event with the same pointerId attribute.
|
Approved
|
|
| 4.2
|
The isPrimary attribute of a pointercancel event must have the same value as the isPrimary attribute of the last pointerdown event with the same pointerId attribute.
|
Approved
|
|
| 4.3
|
The pointercancel event must be followed by a pointerout event. Furthermore, the pointerType and isPrimary attributes of the pointerout must be the same as the respective attributes of the corresponding pointercancel event.
|
Approved
|
|
| 4.3.1
|
The pointercancel event must be followed by a pointerleave event. Furthermore, the pointerType and isPrimary attributes of the pointerleave must be the same as the respective attributes of the corresponding pointercancel event.
|
Approved
|
|
| 4.4
|
If the setPointerCapture method has been invoked on the pointer specified by pointerId, and the releasePointerCapture method has not been invoked, a lostpointercapture event must be dispatched to the element on which the setPointerCapture method was invoked. Furthermore, subsequent events for the specified pointer must follow normal hit testing mechanisms for determining the event target.
|
Approved
|
|
Test Assertions for pointermove events
|
|
Assertion
|
Test Case
|
Status
|
| 5.1
|
The pointerType attribute of a pointermove event must have the same value as the pointerType attribute of the last pointerdown event with the same pointerId attribute.
|
Approved
|
|
| 5.2
|
The isPrimary attribute of a pointermove event must have the same value as the isPrimary attribute of the last pointerdown event with the same pointerId attribute.
|
Approved
|
|
| 5.3
|
When a pointer changes coordinates, the pointermove event must be dispatched.
|
Approved
|
|
| 5.4
|
When a pointer changes button state, the pointermove event must be dispatched.
|
NA
|
|
| 5.5
|
When a pointer changes pressure, the pointermove event must be dispatched.
|
NA
|
|
| 5.6
|
When a pointer changes tilt (tiltX, tiltY), the pointermove event must be dispatched.
|
NA
|
|
| 5.7
|
When a pointer changes contact geometry (width, height), the pointermove event must be dispatched.
|
NA
|
|
| 5.8
|
If pointerType is "mouse" and no mouse button is depressed, then the button attribute of the pointermove event must be -1 and the buttons attribute must be 0.
|
Approved
|
|
Test Assertions for pointerover events
|
|
Assertion
|
Test Case
|
Status
|
| 6.1
|
When a pointing device is moved into the hit test boundaries of an element, the pointerover event must be dispatched.
|
Approved
|
|
Test Assertions for pointerout events
|
|
Assertion
|
Test Case
|
Status
|
| 7.1
|
When a pointing device is moved out of the hit test boundaries of an element, the pointerout event must be dispatched.
|
Approved
|
|
| 7.2
|
When a pen stylus leaves the hover range detectable by the digitizer, the pointerout event must be dispatched.
|
Approved
|
|
| 7.3
|
Pointer Events interface supported.
|
Approved
|
|
| 7.4
|
When a mouse passes through dispatches one event.
|
Approved
|
|
7.5
|
When touch, a device that does not support hover, after firing the pointerup event the pointerout event must be dispatched. See 3.6.
|
NA
|
|
7.6
|
After firing the pointercancel event the pointerout event must be dispatched.
|
NA
|
|
7.7
|
When a pen stylus leaves the hover range detectable by the digitizer the pointerout event must be dispatched.
|
NA
|
|
Test Assertions for pointerenter events
|
|
Assertion
|
Test Case
|
Status
|
| 8.1
|
When a pointing device is moved into the hit test boundaries of an element or one of its descendants, the pointerenter event must be dispatched.
|
Approved
|
|
8.1.1
|
When a pointing device that does not support hover is moved into the hit test boundaries of an element or one of its descendants as a result of a pointerdown event, the pointerenter event must be dispatched. See 2.4.1.
|
NA
|
|
| 8.2
|
The pointerenter event must not bubble up to parent elements.
|
Approved
|
|
Test Assertions for pointerleave events
|
|
Assertion
|
Test Case
|
Status
|
| 9.1
|
When a pointing device is moved off of the hit test boundaries of an element and all of its descendants, the pointerleave event must be dispatched.
|
Approved
|
|
| 9.1.1
|
When a pointing device that supports hover leaves the range of the digitizer while over an element, the pointerleave event must be dispatched.
|
Approved
|
|
| 9.1.2
|
When a pointing device that does not support hover (such as a finger) leaves the hit test boundaries as a result of a pointerup event, the pointerleave event must be dispatched.
|
Approved
|
|
| 9.1.3
|
When a pointing device that has continuous position (such as a mouse) leaves the hit test boundaries of an element, the pointerleave event must be dispatched.
|
Approved
|
|
| 9.2
|
The pointerleave event must not be dispatched when the pointer enters a child element without leaving the hit test boundaries of the parent. (as distinct from pointerout)
|
Approved
|
|
| 9.3
|
The pointerleave event must not bubble up to parent elements.
|
Approved
|
|
Test Assertions for gotpointercapture events
|
|
Assertion
|
Test Case
|
Status
|
| 10.1
|
After pointer capture is set for a pointer, and prior to dispatching the first event for the pointer, the gotpointercapture event must be dispatched to the element that is receiving the pointer capture.
|
Approved
|
|
| 10.2
|
gotpointercapture must be dispatched asynchronously.
|
Approved
|
|
Test Assertions for lostpointercapture events
|
|
Assertion
|
Test Case
|
Status
|
| 11.1
|
After pointer capture is released for a pointer, and prior to any subsequent events for the pointer, the lostpointercapture event must be dispatched to the element from which pointer capture was removed.
|
Approved
|
|
| 11.2
|
lostpointercapture must be dispatched asynchronously.
|
Approved
|
|
| 11.3
|
If the pointer capture target override is removed from the document tree, clear the pending pointer capture target override and pointer capture target override nodes and fire a Pointer Event named lostpointercapture at the document.
|
Approved
|
|
Test Assertions for PointerEvent constructor
|
|
Assertion
|
Test Case
|
Status
|
| 12.1
|
A PointerEvent created with a PointerEvent constructor must have all its attributes set to the corresponding values provided to the constructor. For attributes where values are not provided to the constructor, the corresponding default values must be used.
|
Approved
|
|
Test Assertions for setPointerCapture
|
|
Assertion
|
Test Case
|
Status
|
| 13.1
|
When the setPointerCapture method is invoked, if the provided pointerId value does not match any of the active pointers, a DOMException with the name InvalidPointerId must be thrown.
|
Approved
|
|
| 13.2
|
When the setPointerCapture method is invoked, if the specified pointer is not in active button state, then the method must have no effect on subsequent pointer events.
|
Approved
|
|
| 13.3
|
After invoking the setPointerCapture method on an element, subsequent pointer events for the specified pointer must be targeted at that element. Additionally, the relatedTarget property of all such pointer events must be set to null.
|
Approved
|
|
| 13.4
|
If the Element on which the setPointerCapture method is invoked does not participate in its ownerDocument's tree, throw an exception with the name InvalidStateError.
|
Approved
|
|
Test Assertions for releasePointerCapture
|
|
Assertion
|
Test Case
|
Status
|
| 14.1
|
After invoking the releasePointerCapture method on an element, subsequent events for the specified pointer must follow normal hit testing mechanisms for determining the event target.
|
Approved
|
|
| 14.2
|
Upon invocation of the releasePointerCapture method, if the provided pointerId value does not match any of the active pointers, a DOMException with the name InvalidPointerId must be thrown.
|
Approved
|
|
Test Assertions for touch-action CSS property
|
|
Assertion
|
Test Case
|
Status
|
| 15.1
|
With `touch-action: auto` on a swiped or click/dragged element, EITHER`pointerdown+(optional pointermove)+pointerup` OR `pointerdown+pointercancel` must be dispatched.
|
Approved
|
|
| 15.2
|
With `touch-action: none` on a swiped or click/dragged element, `pointerdown+(optional pointermove)+pointerup` must be dispatched.
|
Approved
|
|
| 15.3
|
With `touch-action: pan-x` on a swiped or click/dragged element, only panning on the x-axis should be possible.
|
Approved
|
|
| 15.4
|
With `touch-action: pan-y` on a swiped or click/dragged element, only panning in the y-axis should be possible.
|
Approved
|
|
| 15.5
|
T-A Processing Model: when a user touches an element, the effect of that touch is determined by the value of the touch-action property and the default touch behaviors on the element and its ancestors. Scrollable-Parent, Child: `auto`, Grand-Child: `none`
|
Approved
|
|
| 15.6
|
T-A Processing Model: when a user touches an element, the effect of that touch is determined by the value of the touch-action property and the default touch behaviors on the element and its ancestors. Scrollable-Parent, Child: `pan-x`, Grand-Child: `pan-x`
|
Approved
|
|
| 15.7
|
T-A Processing Model: to determine the effect of a touch, find the nearest ancestor (starting from the element itself) that has a default touch behavior. Parent: `none`, Scrollable-Child
|
Approved
|
|
| 15.8
|
T-A Processing Model: when a user touches an element, the effect of that touch is determined by the value of the touch-action property and the default touch behaviors on the element and its ancestors. Scrollable-Parent: `none` Child: `auto`
|
Approved
|
|
| 15.9
|
T-A Processing Model: when a user touches an element, the effect of that touch is determined by the value of the touch-action property and the default touch behaviors on the element and its ancestors. Scrollable-Parent, Child: `none`
|
Approved
|
|
| 15.10
|
Change touch action on pointerdown
|
Approved
|
|
| 15.11
|
Touch action button test
|
Approved
|
|
| 15.12
|
Touch action illegal values test
|
Approved
|
|
| 15.13
|
Touch action inherits child 'pan-x' -> child 'pan-y' test
|
Approved
|
|
| 15.14
|
Touch action keyboard test
|
Approved
|
|
| 15.15
|
Touch action mouse test
|
Approved
|
|
| 15.16
|
Touch action 'pan-x pan-y' test
|
Approved
|
|
| 15.17
|
Touch action 'pan-x pan-y' 'pan-y' test
|
Approved
|
|
| 15.18
|
Touch action span test
|
Approved
|
|
| 15.19
|
Touch action table test
|
Approved
|
|
| 15.20
|
Touch action basic verification
|
Approved
|
|
| 15.21
|
Basic touch-action test case to test the interaction between SVG element and touch-action=none. touch-action=none should be effective within the SVG element and touch-action=auto should be effective outside the SVG element
|
Approved
|
|
