RE: Test Assertions gaps

Cathy -

Please create a new pull request to fix #1.

#2> setPointerCapture: added "The pointer MUST be in its active buttons state for this method to be effective, otherwise it fails silently."

This is covered by an existing assertion, 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." Please feel free to update the assertion description (to align with spec) for 13.2.

#5> Added touch-action: manipulation

We have test cases in the queue. We will create a new pull request and then add a related test assertion in the Wiki page.

Re #3, #4, #6, #7 and #8

Our suggestion: it is best to start these with new pull requests and concrete test cases. We will be happy to review these test cases. Once we reach agreement on test cases, then it is easy to create related test assertions in the Wiki page.

-- Asir

-----Original Message-----
From: cathy.chan@nokia.com [mailto:cathy.chan@nokia.com] 
Sent: Thursday, July 17, 2014 3:19 PM
To: public-pointer-events@w3.org
Subject: Test Assertions gaps

I hate to be the person that says "No, wait. We're not quite done yet" and ruins the party, but here it goes...

The test assertions wiki [1] was started and for the most part compiled based on the CR version of the Pointer Events spec [2]. Since then, we've made quite a few changes to the spec. While we've been pretty good at removing test assertions and tests as we remove stuff from the spec, it turns out that we haven't been as efficient in adding test assertions and tests to reflect new additions to the spec. I went through the changes that have been made to the spec since the CR was published, and came up with the following list of changes that have yet to be addressed in terms of testing.

1. PointerEvent.width/height changed from long to double
- the test at https://github.com/w3c/web-platform-tests/blob/master/pointerevents/pointerevent_support.js needs to be updated.

2. setPointerCapture: added "The pointer MUST be in its active buttons state for this method to be effective, otherwise it fails silently."
- Need assertion and test.

3. Setting pointer capture: added "If the Element on which this method is invoked does not participate in its ownerDocument's tree, throw an exception with the name InvalidStateError."
- Need assertion and test.

4. Implicit release of pointer capture: added "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."
- Need assertion and test.

5. Added touch-action: manipulation
- Need assertion(s) and test(s)? 
* Since this is a MAY behavior, I wonder how we want to handle this. Currently, we already have assertions and tests for touch-action: pan-x/y, whose behaviors are also MAY statements. I think I've heard that these tests are useful to implementators. Maybe we should find a way to keep these tests but somehow mark them as optional.

6. pointerdown event: added that for input devices that do not support hover, (in addition to the pointerover event) the pointerenter event must also be fired prior to the pointerdown event.
- Note that this has always been the intended behavior, and was in fact correctly specified in the description of pointerenter event. [[A user agent MUST fire a pointer event named pointerenter when a pointing device is moved into the hit test boundaries of an element or one of its descendants, including as a result of a pointerdown event from a device that does not support hover.]]
- Currently we have Assertion 2.4 that covers pointerover, including verifying matching attributes between pointerover and pointerdown.
[[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.]]
- We also have Assertion 8.1.1 that covers pointerenter, but that does not include verifying matching attributes.
[[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.]]
- We should add the checking of matching attributes to Assertion 8.1.1 and update the test accordingly. (Ideally I would move Assertion 8.1.1 to 2.4.1 and align it with 2.4, but I can live with it staying where it is.)

7. Similarly, for pointerup event: added that for input devices that do not support hover, (in addition to the pointerout event) the pointerleave event must also be fired after the pointerup event.
- As in the previous case, we have Assertion 3.6 that covers pointerout, including verifying matching attributes between pointerout and pointerup.
[[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.]]
- We also have Assertion 9.1.2 that covers pointerleave, but that does not include verifying matching attributes.
[[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.]]
- I would suggest we handle this in the same manner we choose to handle the previous one.
- As an aside, we also have Assertion 7.5 which pretty much says the same thing as Assertion 3.6, sans verifying matching attributes.
[[7.5 When touch, a device that does not support hover, after firing the pointerup event the pointerout event must be dispatched.]]
- I would suggest striking 7.5 and updating the corresponding test to refer to Assertion 3.6 instead.

8. pointercancel event: added that (in addition to the pointerout event), the pointerleave event must also be fired after the pointercancel event.
- We have Assertion 4.3 that covers pointerout, including verifying matching attributes between pointerout and pointercancel.
[[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.]]
- There is currently no assertion that covers pointerleave, so we need a new assertion and test.
- Also, as in #7, we have a duplicate Assertion 7.6 that we can strike.
[[7.6 After firing the pointercancel event the pointerout event must be dispatched.]]

If folks agree that these make sense, I'd be happy to update the assertions wiki - except for #5, which would need input from someone more familiar with the behavior. I can also create a PR to fix the trivial stuff (#1, updating tests to refer to correct assertions etc).

Regards, Cathy.


[1] https://www.w3.org/wiki/PointerEvents/TestAssertions
[2] http://www.w3.org/TR/2013/CR-pointerevents-20130509/

Received on Monday, 21 July 2014 00:12:18 UTC