Re: click and contextmenu events

On Sat, Feb 23, 2013 at 3:22 AM, Jacob Rossi <Jacob.Rossi@microsoft.com>wrote:

>  In IE10, click follows the DOM Events definition, which is that it is
> dispatched to the nearest common ancestor of the down and up events. This
> has the positive aspect that you can extend the physical object analogy of
> touch to UI like buttons:  touching down on the left side then dragging to
> the right and lifting will still activate it (like a physical button).
> Generally speaking, we don’t see accidental activation when dragging (you
> used the term “pan”, but since we’re talking touch-action: none, I’m using
> “drag” so as not to be confused with scrolling). This is because you often
> drag over multiple elements, which means the click will go to some
> arbitrary non-activatable parent element. That said, you’re right that
> there are scenarios where this isn’t ideal (consider a canvas-based map
> where dragging would be over a single element and cause a click). While we
> don’t have immediate plans to change our behavior, I wouldn’t put that
> beyond the realm of possibility. Though I don’t see any definition, beyond
> what’s already called for by DOM Events, being in the scope of this group.
>

Thanks Jacob, that makes sense.  I suppose since mouse already behaves this
way, scenarios like the map one already need to suppress/ignore a click
after drag.  I had forgotten that mouse behaved that way.  Do you think
think we should reference the DOM Events definition in the PE spec (even if
non-normative), or just leave it as is?  Given all the existing touch event
implementations differ here, it seems like an easy source of developer
confusion (and potentially UA divergence).


> Yes, contextmenu is like click (not a compatibility mouse event). Hence
> why I include it in my proposal to use the PointerEvent object. Probably
> worth adding contextmenu to the sentence in PE that says click is not a
> compatibility mouse event.
>

Sound good, thanks.

 -Jacob****
>
> ** **
>
> *From:* Rick Byers [mailto:rbyers@google.com]
> *Sent:* Wednesday, February 20, 2013 2:25 PM
> *To:* public-pointer-events@w3.org
> *Subject:* click and contextmenu events****
>
> ** **
>
> Although it's mostly out of scope, the spec talks a little about click
> events.  I played with the IE10 implementation a little wrt. click (using
> www.rbyers.net/eventTest.html) and was surprised that on a region with
> touch-action:none, ANY pointerup seems to be followed by a click event.
>  This means, for example, that if a map is handling pan gestures, but also
> supports being tapped (eg. to place or select a push-pin), then the
> application needs to have it's own tap gesture recognizer (to avoid taking
> the tap action at the end of every pan).  'click' is an indication that a
> user intends to activate something, I wouldn't have expected the UA to want
> to send that for anything other than a singer-finger tap.****
>
> ** **
>
> The spec has a note that includes "Because it is not a compatibility mouse
> event, user agents typically fire click for all pointing devices, including
> pointers that are not primary pointers".  This covers part of what I'm
> seeing, but not all of it.  Perhaps we should expand this note to describe
> the typical behavior of click in more detail?  This seems like an easy
> place for implementations to differ, resulting in compatibility problems.*
> ***
>
> ** **
>
> If we're going to mention click, should we mention contextmenu too?  It
> seems the behavior in IE is similar (eg. contextmenu still fires even when
> preventDefault is called).****
>
> ** **
>
> Thanks,****
>
>    Rick****
>