RE: pointerout and pointerleave after pointercancel

> From: ext Jacob Rossi [mailto:Jacob.Rossi@microsoft.com]
> 
> 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.
> 

Excellent explanation there! Thanks a lot!

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

That sounds very reasonable to me.

- Cathy.

Received on Friday, 29 August 2014 21:02:27 UTC