IssueTracker

Tested on android 2.3.3 HTC Desire Z. Before e.preventDefault(), touchstart, only first touchmove and touchend are fired. After button click all events are fired properly. Although scrolling doesn't work, zooming works unaffected. However button seems clickable (it highlights). Tested on online version of test.

Let me highlight the mail issue here:

The Android 3.X
----------------
- DOES NOT FIRE touchend if e.preventDefault() is not used

The Android 2.3
---------------
- DOES FIRE touchend if e.preventDefault() is not used

iOS
---------------
- DOES FIRE touchend if e.preventDefault() is not used

Beside this, there is different behavior on touchmove event. All androids fire only the first and than no touchmove is fired if e.preventDefault() is not used, but iOS is firing touchmove events till the page starts to scroll (you can see it if you move your finger to the side), so iOS's touchmove events are related to the content, not the device itself which is correct behavior, because the finger didn't move in relation to the page content (the content is moving with the finger).

There is URL to the test if you don't want to download it: http://www.hawwwran.com/vyvoj/gest.html

I can confirm this behavior.

- On HC 3.2 "touchend" is not called at all
- On iPad the "touchend" is properly called
- On GB 2.3 it works properly and "touchend" is called

To me it looks like a HoneyComb bug that should be addressed and fixed ASAP.
Additionally, the developers should make sure this bug is not present on ICS (Ice Cream Sandwich) too

This bug is present in ICS (4.0.1, Galaxy Nexus), and behaves exactly as described here.

Confirmed on 4.0.3 on Nexus S, bug is still present. It's sad, because even Bada can handle this properly.

The behavior on ICS is the same as on 3.X.
If touchmove event is fired, touchend will not be fired. So once you move your finger, one touchmove is called and then it dies until next touchstart.

The bug is still present in 4.0.4.

Confirmed on 4.0.4 Nexus S

This bug is present just with AndroidBrowser but not with Firefox or Chrome beta for Android. It's ironical

I am experiencing a slight difference in 4.0.3. When touchstart, touchmove, and touchend are wired, applying preventDefault to *either* touchstart or touchmove fixes the issue. I am not required to apply it to both listeners and am still able to listen for clicks if I only apply it to touchmove.

Also, this problem does exist on Chrome for my device. The above solution seems to take care of it under Chrome as well as the stock Android browser.

Well, but applying preventDefault to touchstart or touchmove will disable possibitity to scroll the content of the page. In many cases you don't care about that, but if you want to listen to gestures, this is blocker, because you need to do action only if users input matches some behavior. If you prevent any action, nothing else will be able to use it. If you would listen to gestures over all page, you would kill usability of the page.

If someone from the development team could confirm if this is expected/consciously introduced behavior or not, and if it is expected behavior, whether it's fair to assume that it's going to persist across Android releases that would be useful information. At least it would allow us to "work around" it (accepting whatever trade-offs preventingDefault has), without the behavior changing again in a future release.

Also confirm this bug in Galaxy s2, ICS 4.0.3, stock browser
touchend event is not fired if I slide, but fired only if I "click" screen
preventDefault() in touchstart and touchmove helps, but no page scrolling

Any update on this one? I don't think this is an Android specific issue, but a WebKit's issue. Thanks.

Also interested in some feedback on this

I recently had some experience with this and tried on several different platform and it seems to be intended behavior in webkit. Let me explain what is happening.

If you track touchstart/move/end/cancel you will see that the events that you expect like a lot of touchmove and touchend are not firing because at some point "touchcancel" is fired.

This means that the browser has decided that it will handle the touch and informs you about that by firing touchcancel. Most of the time this happens because it is thinking that browser scroll event should happend.

As a result touchstart/move/end work as expected only when you call e.preventDefault() in touchmove (no need to call it in touchstart event), because you are taking the control from the browser.

Maybe now you are thinking that this limits you to either scrolling or good touch even handling, well no. All you have to do is when touchmove event fires to decide whether you want to use it or let the browser. Let me give you an example:

You need to move some red square with a finger across the screen. The touchstart event fires, and you know that you are on the right element, so you mark somewhere in your code you are on the right place and next time touchmove fire you will call e.preventDefault(), finally when touchend comes you will clear your variable. Voiala! Simple and you still have scrolling and all good touchevents.

That would still prevent you from, say, flicking pictures with scrolling enabled. Unless you go the path where you reimplement scrolling in javascript.

Also, this is android-specific. IOS devices don't seem to display this delinquence.

Exactly as Testo says... if you just want to "listen" user's movement over the page, you can't. I'm using it for gestures... even simple flick gesture to go to another page is impossible to do

This is a blocking bug for someone doing game development or any sort of rich content on a touch device.  The priority far underrated.  It should be rated very high priority.

yes, this is annoying at some point. tested with Android 4.0.3.
touchcancel and touchend is not even fired. actually what i want to get is the coordinates when the finger out of the  screen while letting the default behaviour as is. if touchmove is only fired once, all i get is the coordinate when the finger start touching.

In this ticket, they said it is fixed in Jelly Bean
http://code.google.com/p/android/issues/detail?id=4549

Confirm this bug in a 7in Android tablet (IceCream Sandwich 4.0.3) I purchased 2 weeks ago, as per comment above in 3rd July, this is blocking issue for game development (I'm working on a HTML5 port of fruit-ninja) so would be greatly appreciated if it makes it up the priority list... Thanks!

I ran into this issue today and decided to test whether it was indeed resolved in Jelly Bean. I tested this with the Google Nexus tablet as well as a Motorola Xoom tablet that has Android 4.1.1.

It appears to me that the resolution only applies to the native Android browser and *NOT* to the Chrome for Mobile browser as the bug is very prevalent on the Google Nexus tablet as well as the Chrome for Mobile browser on the Motorola Xoom tablet but *NOT* in the native Android browser on the Motorola Xoom tablet.

I can confirm this bug exists in Chrome for Android 18.0.1025308 on ICS (Android 4.0.3). No other mobile browser exhibits this infuriating behavior. It is particularly frustrating because using e.preventDefault() on touchmove events prevents the browser from vertical scrolling on a vertical touchmove, which is not the desired behavior.

I can't be sure, but I believe the poster who made comment #23 in this thread had his/her facts confused, because that post seems to make little sense.

I confirm this bug on Android 4.0.3 in WebView & Chrome. Also doesn't fired related events such as onmouseup after onmousedown+onmousemove.

I confirm this bug on Android 4.0.4 samsung model number GT-I9300

Samsung Galaxy S2, Dolphin Browser, Chrome Android and Stock Browser. 4.0.4.

On a drop down menu that has onclick events dynamically assigned to its anchor <a> tags with javascript, onclick does not register or fire in Dolphin or Stock. Instead, both browsers seem to assume I'm invoking the double tap to zoom functionality.

If I placed these onclick events outside of this drop down menu, they work fine.

On Chrome for Android, onclick in each element of the same drop down menu works correctly, so I'm pretty sure there is nothing wrong with my CSS or javascript.

It is rather sad that up to now this bug has not been solved. But I wonder if it is an Android bug or a webkit bug. This bug is not present on Firefox, which runs on Gecko. If this were an Android bug, wouldn't it affect Firefox as well, since the bug would be system-wide?

I confirm this bug also on Blackberry Playbook OS 2.1.0.1088.

It completely seems like Webkit bug.

I have an issue which I think is related to this but not 100% sure so let me describe it. I bind the touchend event to a link which will then trigger a function to toggle a simple drop down menu. The problem is that it will not prevent the link from being followed.

I have tried preventDefault on my touchstart and touchend events as well as a return false at the end of my function. Chrome and iOS seem to be the only browsers that get this right. So is related somehow? My touchend event gets fired since my function gets run. I am not 100% sure since even when I preventDefault on touchstart, it still screws it up.

Related problem on Android 4.0;
http://stackoverflow.com/questions/14708618/click-events-not-registered/

I'm still seeing this on the most recent mobile chrome browser ... but I do not see it on androids native browser.

Bug still exists in Chrome Version 27.0.1453.90.
Android's native browser works correctly in this regard.
Tested on HP Slate 7. Android 4.1.1

@33 please report all bugs with Chrome to http://crbug.com/

I am seeing it also on Samsung Galaxy 3 {4.1} build. It shows an erratic behavior where it fires sometimes and sometimes it doesn't. We have built pages which snap on the scroll and the event of touch move has to be considered

I get issue :  singleCursorHandlerTouchEvent -getEditableSupport FASLE

Pretty frustrating as I don't see these problems in ios

I've found a workaround that works pretty good for me.
On the touchstart event, store the touch coordinates. Then on the touchmove event, only do event.preventDefault() if the difference in X is more then 10 pixels and in Y is less then 25.

The code looks like this:
if (Math.abs(movingTouch.clientX - this.initialTouch.clientX) > 10 && Math.abs(movingTouch.clientY - this.initialTouch.clientY) < 25) {
        event.preventDefault();
}

This is probably by design.  Once scrolling starts you can no longer get touch events (since they're being used to scroll).  Behavior differs a bit between browsers (eg. Chrome Android sends 'touchcancel').  Some discussion about the right behavior across different browsers is here: http://lists.w3.org/Archives/Public/public-webevents/2013AprJun/0040.html

Fixed in 4.1

Bugs in Chrome should be filed at crbug.com

It comes back in 4.4

yeah, event touch come back in android 4.4

running android 4.4.2 has this bug

come on Google, what's wrong with you? How is this possible, that this bug comes back? It's really annoying!

I came across this problem as well but after some digging on the web I concluded that this might be an intended behaviour from Android guys. So, you better try to use e.preventDefault() to "work around" which in fact is the correct approach to the issue instead of waiting for a fix which may never come.

It't not correct behavior, since I don't want to change the default bevavior, but just "listen" to gestures. With e.preventDefault() you even can't scroll.

If with "intended" you mean someone that does not understand the workings of touch events, continuously steers towards the wrong behavior, than it may even be, but that does not mean it is right.

Let me clear it out.

1) This is a *BUG*, and serious at that, it is definitely *NOT* the correct behavior.

2) *there* *is* *no* *workaround*. And unfortunately there will not be for some time, as older versions of Android will be around for long, actually reducing the possible usable interactions of web pages for years to come. Unless you call "workaround" manually handling all the scrolling of a website *instead* of the browser, trying to emulate the browser behavior (same inertia, same speed), but unfortunately you will never get it right as there are many different browsers and platforms with different behaviors.

3) How can anyone say calling e.preventDefault() is a workaround? That is exactly what you *DO* *NOT* want to do in this cases. If you want the page to scroll you definitely need *NOT* to call e.preventDefault(). But if you do not call e.preventDefault() you do not get touch events, so you cannot for instance move a slider and let the page scroll together.

4) Apparently the bug *WAS* finally fixed in 4.1, so a "fix which may never come" actually was there some time ago. It is just that someone, who does not understand it (like you), reverted it back. Complaining is not only legit, but necessary so that the right people understand the bug is real and serious.

5) And for the proposed solutions like: "only do event.preventDefault() if the difference in X is more then 10 pixels and in Y is less then 25" I sincerely doubt they worked for you!!! If you do not call event.preventDefault(), then the "the difference in X" will never be updated as no event is triggered anymore!!! That is *the* bug, remeber? That code is exactly how it should be done *if* there was not this bug!

So in conclusion, please, if you do not know what you are talking about and do not understand it, do not write about it, underestimating the problem. It is insulting to all that have accurately reported it (and I am not one).



There is only one solution,   p l e a s e   f i x   t h i s.

(Apple did it right, guys, can't you?)

Just came across this issue, preventDefault is NOT a solution, stop saying that it is...
GOOGLE Fix this issue!

Can confirm this issue, prevents (mobile) devices from using swipe when a custom function is required.
This should be a high priority fix as it hampers user experience.

Works as expected in other browsers (like Safari).

I'm experiencing the same issue here. The preventDefault hack breaks scrolling. But without it I can't use swipe events in my app.

1 month with this issue.. my app lost 0.5 points on Google Play Store :(

I confirm this issue on Nexus 10 with Android 4.2.2.
And also with Asus Nexus 7 with Android 4.2.1.
Earlier I had put e.preventDefault() fix but had to revert it as it was blocking vertical scrolling.
For now, as a work around, I have tried what is suggested in comment#38. It is good for me so far. Thank you!
I really wish, Android Dev team fix this on priority.

Please fix this issue Google. the issue is there for 4.4

I'm aware of that issue it's not that simple actually.

 Android 4.4.2; Nexus 7. Iam stuck. !
putting event.preventDefault() in touchmove triggers "touchend" but cant find a suitable place to put the statement.

i guess the google implementation is fine. If the browser is detecting a scroll gesture it cancels the touch event("touchcancel") and native browser scrolling takes over.

Derk.sac (#56), you are wrong. If you want to know why, read comment #47, which explains it exceptionally well.

Please FIX this ASAP

My app built from PhoneGap Build cloud service runs well in Android 4.0, 4,1, 4.2 and 4.3.

In Android 4.4 it doesn't detect swipe. I've heard it's related to this issue, any upgrade on how's the bug going, or if someone is working on its fix?

[Comment deleted]

The broken behavior (Android 4.0 and 4.4) is actually more convenient for some use cases, even though it's obviously broken. What I would suggest is taking the broken behavior of touchend (where it doesn't fire after scroll), and make a "tap" event that works exactly like that (and stop triggering a touchcancel when the page scrolls).

I always found it odd that there is a "click" event, but no corresponding "tap" event. "tap" and "click" events - very convenient! Here's a change to fix it right.

I'm encountering the same behavior in the Chrome browser on a Nexus 5 running Android 4.4.3.  Unless I use preventdefault on touchstart or touchmove, the touchend event never fires.  My use case is to enable a sideways swipe gesture, but only if the user demonstrates commitment to it by swiping horizontally for a threshold distance first (to be calculated as of the touchend event).  I don't want to use preventdevault because it will stop normal vertical scrolling.

The W3C recommendation for the touchend event (www.w3.org/TR/touch-events/#the-touchend-event) is working as expected for me, without the need for preventdefault, in mobile Safari on an iPhone, iPad Mini, and an iPod Touch.  Ironically, it also works fine in Firefox on the same Nexus 5 and in Chrome on a Nexus 1 running Android 2.3.6.

Frustrating, and surprising that this hasn't been fixed yet.  Or, if it's supposed to be a new intended behavior, that the deviation hasn't been documented as such.  There is a seemingly related discussion in a W3C forum archive:
lists.w3.org/Archives/Public/public-webevents/2013AprJun/0040.html
lists.w3.org/Archives/Public/public-webevents/2013AprJun/0045.html

Faced the same issue in MOTO X and nexus 7 Android 4.4.4


Please fix this.

mattn (#62) did you end up finding a solution? I'm trying to implement a gesture that sounds about identical to yours.

Guys I don't know it it helps to anyone of you but try to call same function on both touchend and touchcancel. For example
document.getElementById('mydiv').addEventListener('touchend', somefunc, false);
        document.getElementById('mydiv').addEventListener('touchcancel', somefunc, false);

It is almost three years since the bug was reported. Why no solution yet? Google, kindly share your explanation..

In reply to ianfo (#64):  Sort of.  Rather than a solution, I'd call it more of a workaround.

I'm making a very early evaluation upon the first touchmove event.  Comparing the position's change from touchstart to the first touchmove, if the user's "vector" seems sufficiently fast and horizontal, I issue preventdefault and otherwise ignore it.  If the absolute value of the touch position's dx is > 6 and its dy is < 3, I treat that as "sufficiently rapid and horizontal."  If I wait any longer to evaluate, the more modern mobile Chrome issues a touchcancel.  Having to make such an early evaluation is suboptimal, but it seems to be working well enough for my current purposes.  I also monitor the subsequent touchmove events, and if for any of them the dy's absolute value is > 2, I don't treat that move as relevant input for my use case.  That wouldn't be helpful however if my use case had to be an all or nothing response to user input.

Shim @ https://github.com/TNT-RoX/android-swipe-shim

Google - Please fix this, or explain why you have broken so many web apps

Touch-Action css is linked to this issue as well, and that has been pulled from M35

Seems fixed in Chrome 36

Gamsung Galaxy Tab S - Chrome 39
A scrollable div on a page gets click and touch events until it gets it's first touchmove event. After the touchend event it gets no click and touch events anymore. The "native" browser on this device still gets the click and touch events. Seems very wrong to me.

Moto G 4.4.4  - the same bug in WebViews ...

Did somebody found how to detect if browser has such bug? I am thinking to emulate scrolling and clicking myself on broken ones, but because I expect it will make scrolling lag I want to enable this only on broken ones.
Android Browser 5.13 on Android 4.4.2 has this bug for example. But Chrome on same Android is ok.

Is this still broken in Android 5+ WebViews?

Also, where is that new tap (think click for touch) event?

Problem issued in lollipop version of nexus 7
..
when using canvas if image is sketched then when text area or any other text field if clicked the canvas page automatically opened ...
solution please??..
 

This approach worked for me (have a horizontal scrollable slider width clickable images in it - modified from http://iliketomatoes.github.io/elbajs/):

onTouchStart : function(e) {
  // caching the current x and y
}

onTouchMove : function(e) {
...
  //We just want horizontal movements
  if(Math.abs(self.points.cachedY - self.points.currY) >= Math.abs(self.points.cachedX - self.points.currX)) {
        return false;
  } else{
        e.preventDefault();
  }
...
}


Lets me now scroll the slider, tap on the images for the link, and scroll the page vertical...
Tested in
Android 2.3.6 browser
Android 4.1.2 browser
android 4.1.2 chrome
iPhone 6+ safari
iOS iPad Air 8.3
win7 Chrome Version 44.0.2403.157 m
win7 firefox 42.0a2 (2015-08-27)
win7 ie 11
win7 ie 9 (some issue with the link...)

best
/javier

win7 ie 9 (emulated)

"identifier" property is always 0 to me in Android Chrome (both latest version)

This is still on my Android 4.4.2 device. I can't believe!!! Is there move clearer workaround possible?

Bug Confirmed on Galaxy S5 - Android version 5.0

2021 and this bug still going on?

2022 and this bug still persists