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

Re: Internet Explorer Mobile Touch Events support

From: Rick Byers <rbyers@google.com>
Date: Fri, 1 Aug 2014 19:58:49 -0400
Message-ID: <CAFUtAY_YzurCYPwiDwCJ_VCbTqTyHRErdVW4tNe8qtGTpeco7g@mail.gmail.com>
To: Matt Brubeck <mbrubeck@mozilla.com>
Cc: Jacob Rossi <Jacob.Rossi@microsoft.com>, "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 Fri, Aug 1, 2014 at 4:02 PM, Matt Brubeck <mbrubeck@mozilla.com> wrote:

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

Interesting.  In chromium I don't think we'd have an issue here because we
already keep touch events queued up in our browser process - handing one at
a time to the process responsible for the page.  So I think we already
effectively hit this situation today - we may receive a touchend from the
OS before we know whether the page wants to handle the touchstart.  If we
decide (in our old touchcancel model) that scrolling has started, then we
inject a touchcancel ahead of all queued events.  When draining the queue
we discard events for a touch point that we'd already cancelled.

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

Of the top of my head this sounds reasonable to me.  It seems like a nice
property that you must use touch-action if you want to continue receiving
pointer events.  It does mean, however, that apps trying to implement
effects that can't currently be implemented with touch-action alone (eg.
pull down to refresh) will be forced to use touch events.  Keeping the
models separate in this way seems like the cleanest model to me.
Received on Friday, 1 August 2014 23:59:37 UTC

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