You can clone with
Scrolling in a list up or down with your finger slightly moving left or right will cause a swipe event. Use of this is if a user is using one hand to hold the mobile device then use the thumb to scroll you are going to get an arch motion.
May a check should be put in play to check the x vs y to see if it is more of a swipe motion or scroll motion.
I am using 1.0b2 and had to disable swipes because of this issue. We tested both iOS and Android and duplicated the issue several times on both devices.
Possibly related to #341
Why don't you configure your swipe thresholds to be less sensitive as documented in the Beta 2 announcement? I changed this in my own application and the swipe left/right sensitivity is much better once the threshold values were increased.
That could possibly be a temp fix but you shouldn't have to increase threshold. A fix should be put into place to actually determine if the intended swipe was more of a vertical swipe or horizontal swipe. I shouldn't have to set the threshold to my entire screen. If I only wanted to use 10px to use swipes I should be able to use those 10 pixels instead of having to set my threshold to 75.
Many people use just a small portion of their screen to do the swipe events if they are using one hand to hold the phone and do the swipes. Setting the threshold to higher will cause issues for people that only use a small portion of the screen.
So, then set your vertical threshold to a lower value. All applications aren't going to be the same so I hope a "fix" isn't put in that works better just for one use case. That's what's nice about the current event threshold configuration, you can adjust it to fit the needs of your application without forcing everyone else to fit the same use cases.
Its not just a one use case. A check needs to be put into place to determine if it indeed is a vertical swipe or a side swipe. If I have 2 sections in my app, one large and one small and I need to detect swipes inside them it setting the global preferences for the threshold will not work. Setting my threshold high for the large section will make my small section not register the swipes. Setting my swipes small for the small section will cause my large section to register incorrect events should a user add a little horizontal swipe to their vertical swipe (IE: using one hand to hold the phone and using the thumb to do swipe / gestures). Adding a check to see if the x.start - x.stop are larger than y.start - y.stop then we know its more of an x swipe than y and vise versa.
I don't think this thing is entirely fixable by better thresholds. The thing is also, when a user scrolls, the start coordinates also move. That means when you do a fast arc up and down, start and end coordinates end up looking like you swiped horizontal.
Maybe we should take both scrolling and the angle into account.
Changing coords to use clientXY instead of pageXY seems to fix the latter problem of scrolling up and to the side being considered a swipe.
My comment on using clientXY was premature. Based on a simple test I did with the iOS 4.3.3 simulator, all pageY, screenY and clientY report values relative to <body>. So when scrolling a long page vertically, they remain roughly the same.
Maybe we'd need to track scrolltop, too, to short-circuit the swipe when it's really a scroll.
Update: iOS 5.0.1 seems to report ev.clientY relative to the actual screen. Ev.pageY and ev.screenY are still equal.
related issue #3823
Update: actually not only related, but the same so I closed that one as duplicate.
The content you are editing has changed. Reload the page and try again.
Touch scrolling (really touch drag scrolling) means having the content move on the screen along with your finger; so there is little relative vertical movement between your finger and the content, even if you have dragged your finger up or down more than half the screen.
To fix this issue, I added scrollTop tracking to the swipe event. The pending pull request is here: #4478
Attach images by dragging & dropping or
Uploading your images…
Unfortunately, we don't support that file type.
Try again with a PNG, GIF, or JPG.
Yowza, that's a big file.
Try again with an image file smaller than 10MB.
This browser doesn't support image attachments.
We recommend updating to the latest
Google Chrome, or
Something went really wrong, and we can't process that image.
We have tested this with this test page: http://goo.gl/irGhT
On Android there were no issues with a swipe event being triggered while (touch drag) scrolling. The problem seems to only occur on iOS.
Wondering if this could be adjusted by increasing the thresholds a bit?
After some research and discussion with @toddparker we are going to fix this by making some of the calculations available to modify to add your own swipe left right behavior like using scrolltop for calculation as mentioned above.
Swipe Event: made it possible to hook to the start and stop objects a…
…nd swipe event handler to allow custom implementations and extensions. Fixes #2328 - Scrolling up and down causes swipe event
The swipe event can now be extended to add your own custom behavior or or added swipe directions like up and down. This will be in 1.3 you can see an example extension at https://github.com/arschmitz/JQM-Swipefix this extension will fix this issue on iOS.
Cross references: if a better solution found, could also update http://forum.jquery.com/topic/scroll-issue-on-swipe-elements and http://stackoverflow.com/questions/11290771/swipeleft-swiperight-triggered-during-vertical-scroll-in-jquery-mobile
Information only: Documentation says: "On iOS no vertical distance takes place in the touch events while scrolling. This means that the verticalDistanceThreshold specified for the swipe event is ignored. The only way we have found to work around this is to calculate scrollTop on every touchstart / touchend which is very expensive. It is for this reason we have made the swipe event extendable so you can add this in if the performance is acceptable for your use."
How did we want to include that swipe fix? In the demos?
Is there a reason for not using screenX/screenY instead of pageX/pageY? There is still an issue in Firefox for Android where a vertical scroll is recognized as a swipe.
However using screenX/screenY fixes the issue and also works in all the browsers I tested (Firefox, Chrome for Android, Default Android Browser, Safari for iOS 6.0). Maybe you should use screenX/screenY whenever possible and fall back to pageX/pageY for older browsers.
See http://jsbin.com/uzedeq/15/edit for an example of the issue. In Firefox for Android a swipe is detected although the page is just scrolled. The best way to reproduce this issue seems to be to scroll with a lot of acceleration (like when you are at the bottom of the page and need to get back to the top).
If you do not want to change the default handler maybe at least add a hint to the docs.
@mk747gx Thank you for your efforts on this however screenx/screeny reports the same results in this case and does not fix or improve the issue. tested this morning on ios5/ios6, chrome for ios, and android
But it certainly does fix the issue in Firefox for Android. When scrolling pageY stays the same while screenY reports the correct value.