Emulate touch events - event order different from real devices
Reported by splinte...@gmail.com, Mar 8 2013
UserAgent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_8_2) AppleWebKit/537.33 (KHTML, like Gecko) Chrome/27.0.1431.0 Safari/537.33 Steps to reproduce the problem: 1. enable "emulate touch events" 2. log the order in which touch events and simulated mouse events are fired 3. note the difference between the order and a real touch device What is the expected behavior? the current touch emulation results in a different sequence of events compared to real touch-enabled devices. real device: touchstart > [touchmove]+ > touchend > mouseover > mousemove > mousedown > mouseup > click dev tools: touchstart > mousedown > [touchmove > mousemove]+ > touchend > mouseup > click What went wrong? the touch events don't fire in a group first, before the mouse events, as happens on a real device. in most cases, this isn't a big issue, but can lead to false expectations with regards to how events can be preventDefault-ed or caught. Did this work before? No Chrome version: 27.0.1431.0 Channel: n/a OS Version: OS X 10.8.2
Mar 10 2013,
Mar 11 2013,
Jul 23 2013,
Issue 262008 has been merged into this issue.
Sep 9 2013,
Rick, this is the bug tracking the event order discrepancy that you seem to have had ideas about...
Sep 9 2013,
Ah yes, this is very related to the issue I filed recently: bug 278300 . I think the fix is basically the same - touch emulation needs it's own simple gesture recognizer (or a way to re-use the system one on platforms that have one like Aura). Once it has that, then it can suppress the real mouse events entirely (and rely on the gesture code path in blink to emulate mouse events in the same way as a real touch screen). Since the actual input is coming from a mouse, and to start we can probably get away with only firing GestureTapDown/GestureTap/GestureTapCancel events, this probably wouldn't be that hard. Basically just need some code in blink that calls HandleGestureTap* methods appropriate for touch emulation (based on a simple definition of what constitutes a 'tap' when actually using a mouse). I'm happy to discuss further if you like.
Sep 24 2013,
Oct 24 2013,
Dec 3 2013,
FWIW in Chrome 33.0.1727.0 canary touch emulation now fires the following touchstart > mouseover > mousedown > touchend > mouseup > click (note the mouseover, which I *think* wasn't there before when I tested in 27) Still in the wrong order though (mouseover and mousedown should come after touchend)
Dec 4 2013,
Yep. Still waiting for synthetic gesture processor to be ready.
Feb 14 2014,
for completeness' sake, also wanted to note (only just noticed as I modified my tests): even when touch emulation is enabled, mouseenter/mouseleave are being fired when the mouse button is not pressed.
Apr 22 2014,
This is fixed by new touch emulation implementation.
Sign in to add a comment