RE: pointerout and pointerleave after pointercancel

On Mon, Aug 4, 2014 at 11:18 PM, Sangwhan Moon <smoon@opera.com> wrote:
>
> On Tue, Aug 5, 2014 at 6:30 AM, <cathy.chan@nokia.com> wrote:
>>
>> This question stems from Sangwhan's review [1] of a test case that I submitted [2], which was a clone of another test from Microsoft [3].
>>
>> The tip of the PE spec says the following about pointercancel.
>> [[
>> After firing the pointercancel event, a user agent MUST also fire a pointer event named pointerout followed by firing a pointer event named pointerleave.
>> ]]
>>
>> In comparison, it says the following about pointerup.
>> [[
>> For input devices that do not support hover, a user agent MUST also fire a pointer event named pointerout followed by a pointer event named pointerleave after dispatching the pointerup event.
>> ]]
>>
>> The question here is whether the statement on pointercancel truly does apply to all pointer types (i.e. including those that support hover) and what the rationale is. (Or was that just an unfortunate bug in the spec?)
>
>
> While I'm not knowledgable enough to comment on the rationale, from the back of my head this doesn't look like a bug.
>
> Leaving it open ended for input devices which do not fall into the three common device categories defined by the specification - e.g. a stylus with no proximity triggered pointer interaction could benefit from being open ended. The only real world example I can think of is this thing: http://www.wacom.com/en/us/creative/intuos-creative-stylus
>
> The stylus above activates based on touch screen, but conceptually is a pointer type of stylus with pressure (the pressure information is transmitted over bluetooth), and has no support for hovering. I don't know any browser that has support for this particular piece of hardware, but worth noting that such devices exist.

Yeah, this isn't a bug. The key thing here is making sure state machines built around over/out or down/up don't get stuck.  So you want to be sure that if a pointerdown event fires, then a paired pointerup or pointercancel eventually fires. Likewise, if a pointerover fires, then a paired pointerout better eventually fire too.

When a hover capable device comes up, it's still hovering the element and thus is still "over" it. But when a non-hover capable devices comes up (e.g. finger lift), you'll never know when it leaves the element so it must be considered no longer over the element and thus a pointerout/leave is necessary.
Likewise, a pointercancel indicates the pointer has been absorbed or otherwise not likely to produce further events. Therefore, you also need to clean up the over state by firing out.

>>
>> A follow-on question: why is the test case that checks that the pointerout event follows the pointercancel event [3] written to be specific to touch input? What about mouse and pen input?

While the normative statement for this assertion isn't specific to touch, triggering a touch action (pan/zoom) is the only normatively defined and repeatable scenario in which pointercancel fires. So this test just uses that scenario to validate the event order.

Received on Friday, 29 August 2014 20:26:03 UTC