W3C home > Mailing lists > Public > public-pointer-events@w3.org > July to September 2014

Re: Internet Explorer Mobile Touch Events support

From: Matt Brubeck <mbrubeck@mozilla.com>
Date: Fri, 01 Aug 2014 13:02:09 -0700
Message-ID: <53DBF241.20504@mozilla.com>
To: Rick Byers <rbyers@google.com>, Jacob Rossi <Jacob.Rossi@microsoft.com>
CC: "Patrick H. Lauke" <redux@splintered.co.uk>, "public-pointer-events@w3.org" <public-pointer-events@w3.org>, "public-touchevents@w3.org" <public-touchevents@w3.org>
On 08/01/2014 11:46 AM, Rick Byers wrote:
> Also, any idea how this matches Firefox's approach for supporting both 
> types of events?  I know at one point they were considering an 
> either-or model of firing the events, but hopefully I persuaded them 
> that would be a bad idea.

Our work-in-progress implementation fires both sets of events.  We did 
run into one interesting question:

Without touch events, the input thread does not need to wait for the 
main (script) thread to decide whether to begin scrolling.  Based on the 
input and the touch-action property, the input thread can send a 
pointercancel event (and suppress further pointer events) as soon as a 
scrolling gesture begins.

With touch events, things get trickier.  Scrolling can't start until 
script finishes handling the touchstart and touchmove events.  What if 
the input thread receives further input while waiting for this 
processing, possibly including a pointerup event?  It would need to 
queue up that input until it learns whether the touchstart and touchmove 
events were canceled, and then either suppress it or dispatch it.  This 
would significantly complicate implementation, and change the behavior 
and timing of pointer events compared to browsers without touch events.

We are considering the following behavior:  As soon as a touch gesture 
with a default action begins, check whether the default action is 
allowed by touch-action.  If it is allowed, immediately send 
pointercancel and suppress further pointer events for that touch, 
*regardless* of whether any touch events are subesquently canceled or 
not.  If the default action is not allowed, then continue sending both 
pointer events and touch events.

The effect for content authors is that, if they want to continue 
receiving pointer events, they *must* use touch-action to prevent 
default actions. (Just calling preventDefault on touch events is not 
sufficient.)  This is already the case for browsers like IE11 that 
support pointer events without touch events, so we don't think this will 
cause any compatibility issues.  However, it could certainly be 
surprising to authors.
Received on Friday, 1 August 2014 20:02:39 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 16:48:10 UTC