New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.
Starred by 18 users

Issue metadata

Status: Fixed
Owner:
Closed: Apr 2014
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Mac
Pri: 2
Type: Bug

Blocked on:
issue 337142



Sign in to add a comment

Emulate touch events - event order different from real devices

Reported by splinte...@gmail.com, Mar 8 2013

Issue description

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
 
Project Member

Comment 1 by bugdroid1@chromium.org, Mar 10 2013

Labels: -Feature-DevTools Cr-Platform-DevTools
Owner: apavlov@chromium.org
Status: Assigned
 Issue 253881  has been merged into this issue.
 Issue 253881  has been merged into this issue.
 Issue 262008  has been merged into this issue.
Cc: rbyers@chromium.org
Rick, this is the bug tracking the event order discrepancy that you seem to have had ideas about...
Labels: Cr-UI-Input-Touch-Screen
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.
Cc: apavlov@chromium.org
Owner: dgozman@chromium.org

Comment 9 by rbyers@chromium.org, Oct 24 2013

Labels: -Cr-UI-Input-Touch-Screen Cr-Internals-Input-Touch-Screen
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)
Cc: kaznacheev@chromium.org
Yep. Still waiting for synthetic gesture processor to be ready.
Blockedon: chromium:337142
I believe the right fix for this class of problem is  issue 337142 
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. 
Status: Fixed
This is fixed by new touch emulation implementation.

Sign in to add a comment