Re: Errata for Touch Events: section 7 and what happens with more than a single finger

Thanks for this test case.  Playing with it I found a bug
<https://code.google.com/p/chromium/issues/detail?id=439190> in Chrome (try
dragging the first finger instead of just holding it there - then we behave
like Safari and you never get any events).  Chrome and Safari's issue are
probably both due to the optimizations we have to try to skip touch
handlers when we think we can do it without the page being able to tell (to
make scroll start faster).  I'll make sure our bug is fixed so that we
consistently get touch events for the finger over the button.

Note that there's a particularly tricky problem about what to do with the
'target' in the event for the first touch point.  Since the first finger
went down where there is no handler, we really don't want to do a hit test
for it (and therefore block scrolling on the javascript thread).  But when
the second finger goes down over a handler, we have to tell you _something_
about the first.  I think we just report a null target in this weird
special case.  It's cases like this that make me prefer the
one-event-per-point style API used by pointer events ;-)

Maybe the simplest thing you could do here is replace "If the user agent
intreprets a sequence of touch events as a click" with "If the user agent
intreprets a sequence of *single finger* touch events as a click"?  I agree
it's not worth trying to say anything about multiple fingers.  Eg. ChromeOS
actually has a two-finger tap gesture for triggering right click (because
some people just couldn't handle waiting 1s for their context menu <grin>)
which does send mousedown/mouseup.

Rick

On Mon, Nov 10, 2014 at 10:36 AM, Patrick H. Lauke <redux@splintered.co.uk>
wrote:

> On 30/10/2014 02:08, Patrick H. Lauke wrote:
>
>  On 06/10/2014 18:40, Rick Byers wrote:
>>
>>> I'm fine with the stuff you're calling "implementation specific" as long
>>> as the implementations agree (either already implement what you
>>> describe, or agree we should implement it).
>>>
>>
>> I've just retested this on a few devices/browsers (Android, iOS,
>> FirefoxOS). It seems there are two models implemented in the wild, based
>> on testing with
>> http://patrickhlauke.github.io/touch/tests/event-listener.html ... place
>> a touch anywhere that's NOT on the test button first, keep it there,
>> then try to tap the button:
>>
>> - some browsers (e.g. Android/Chrome) only fire touchstart >
>> (touchmove)+ > touchend
>> - some browsers (e.g. Android 4.3/Browser, and surprisingly Safari/iOS8)
>> don't fire ANY events
>>
>> If you tap with two fingers simultaneously on the test button, browsers
>> seem to agree a bit more and only fire touchstart > (touchmove)+ >
>> touchend (though depending on how "simultaneous" the tap was, you may
>> actually get more than one touchstart/touchend...but the main point is
>> no mouse or click events, with the exception of old Webkits that still
>> fire the mouseover > mousemove BEFORE touchstart).
>>
>> So the question is: is it worth me trying to come up with some
>> generic-enough sentence that says something along the lines of "this
>> spec only defines the behavior for compat events in the case of a single
>> finger tap...anything else can and will be weird/inconsistent"?
>>
>
> *bump* ... worth me having a look at this?
>
>
> P
> --
> Patrick H. Lauke
>
> www.splintered.co.uk | https://github.com/patrickhlauke
> http://flickr.com/photos/redux/ | http://redux.deviantart.com
> twitter: @patrick_h_lauke | skype: patrick_h_lauke
>
>