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

Issue 363319 link

Starred by 4 users

Issue metadata

Status: Duplicate
Merged: issue 293467
Owner: ----
Closed: Apr 2014
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Android
Pri: 2
Type: Bug



Sign in to add a comment

Swiping over a button with touch event handlers results in a single touchmove then touchcancel

Reported by splinte...@gmail.com, Apr 14 2014

Issue description

Steps to reproduce the problem:
1. open http://patrickhlauke.github.io/touch/tests/event-listener.html
2. touch the button and swipe a tiny bit
3. lift finger from touchscreen

What is the expected behavior?
Looking at the results of doing the same in iOS7/Safari, Android4.3/Firefox and even Android4.3/"Browser", I'd expect the sequence of events being fired:

- touchstart
- (touchmove)+
- touchend
(and, if movement below a certain threshold, mouse compat events, but that's irrelevant for this case)

What went wrong?
Chrome M34 fires:

- touchstart
- a single touchmove
- touchcancel

I could hazard a guess and say this is touchmove absorption? Is this intended behavior then?

Did this work before? N/A 

Chrome version: 34.0.1847.114  Channel: stable
OS Version: 4.3
Flash Version: 

See https://www.youtube.com/watch?v=3RZkeVe5M9M - i note that M35 beta is actually behaving as expected...just want to confirm if what I'm seeing in M34 (and other related browsers, like Opera) was indeed a bug and that M35's is the correct behavior going forward?
 

Comment 1 by rbyers@chromium.org, Apr 14 2014

Cc: jdduke@chromium.org
Labels: -Cr-Blink-JavaScript Cr-Blink-Input M-34
Mergedinto: 293467
Status: Duplicate
This "bug" makes me happy :-)

What you're seeing in M34 is what Chrome on Android has always done and it's a constant source of confusion (see  issue 293467  and related bugs duped into it).

What you're seeing in M35 is the new "touchmove absorption" model I'm trying to get us to switch to (see  issue 346693 ).  Note that touchmove events are dropped when you're actually scrolling so it's not completely unsurprising, but I assert that this behavior is much less surprising and error-prone than our previous touchcancel behavior (but there's active debate on this point, eg. see https://docs.google.com/a/chromium.org/document/d/1MGuCb0Lb7UfaDmH44bp9YKVG-CVfH6WtKTZl93BXwQw/edit#heading=h.b4v4t2tivm3p).

Unfortunately we've had to disable absorption in M35 (so the next M35 build will behave like M34) - see  issue 360614 .  But we're trying to work around the issues and launch again in M36.  I'd love your feedback in the doc above or on this input-dev thread: https://groups.google.com/a/chromium.org/forum/#!topic/input-dev/vwDPmoRHboM

Context for others: Patrick has spent a lot of time studying touch event behavior, talking at several conferences about it, and is a member of the touch events community group and pointer events working group.  If HE thinks Chrome 34 has a bug here that was fixed in Chrome 35, that's a very strong signal in my mind that we're on the right track with touchmove absorption...

Comment 2 by rbyers@chromium.org, Apr 14 2014

By the way, you can see the difference more directly by changing 'touch-scrolling-mode' in chrome://flags.

Sign in to add a comment