Re: Test Assertions gaps

I would say that we should create the test assertions on the wiki now,
otherwise it's giving a false impression of completeness.


On Sun, Jul 20, 2014 at 8:11 PM, Asir Vedamuthu Selvasingh (MS OPEN TECH) <
asirveda@microsoft.com> wrote:

> 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/
>
>
>
>