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