- From: Matt Brubeck <mbrubeck@mozilla.com>
- Date: Fri, 01 Aug 2014 13:02:09 -0700
- 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