Re: Internet Explorer Mobile Touch Events support

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.