Swipe is buggy on Chrome/Android #5534
Comments
|
Do you mean swipe on the panel or on the page? The latter has been added after 1.3 beta 1 so that works with latest code. Haven't noticed issues with that on Android. Closing as fixed. If you still see an issue, please comment and provide a test page. Also, include information about Android version, jQuery core version, etc.. See the contributing guidelines. |
|
The panel is not closed when swipe both on the panel and page. Only closed On Sat, Jan 26, 2013 at 1:21 AM, Jasper de Groot
|
|
The panel is not closed when swipe both on the panel and page. Only closed when touch the page. It seems the swipe event is not captured in Android. Testing page: |
|
Testing page: On Sat, Jan 26, 2013 at 10:54 AM, Xu Zhong dzhongxu@gmail.com wrote:
|
|
Same page, latest code: http://jquerymobile.com/test/docs/panels/index.html |
|
I can still reproduce it in Android 2.3.0 Galaxy S3 and 2.3.6 Galaxy S1.
|
|
Sorry for Galaxy S3. It is Android 4.1.1. On Sat, Jan 26, 2013 at 11:14 AM, Xu Zhong dzhongxu@gmail.com wrote:
|
|
Just tested http://jquerymobile.com/test/docs/panels/index.html on a Galaxy Nexus running Android 4.1.1 and I don't see any issue. Does swipe work on your device if you test these demos? |
ghost
assigned
|
No. The swipe does not work in those two links, on Android S1 and Android On Sat, Jan 26, 2013 at 12:14 PM, Jasper de Groot
|
|
I just tested all links above on Samsung Galaxy S3 (Android 4.1.2) on the native browser and aldo all swipes work, it's very hard en not consistent, I had to try multiple times in most cases. I also tested it on Chrome, Chrome beta, Firefox, Firefox beta and Opera Mobile, I had no issues with the swipes. |
|
I changed the title of this ticket because it is not a panel issue but a swipe problem. Swipe doesn't work on: Issue cannot be reproduced on: test pages: |
|
Thanks! |
|
http://www.photoswipe.com/latest/examples/04-jquery-mobile.html#&ui-state=dialog Swipe works on Galaxy S1, S3 and Note2. On Sat, Jan 26, 2013 at 12:34 PM, Xu Zhong dzhongxu@gmail.com wrote:
|
|
@uGoMobi Yeah every swipe action was buggy. In the end the action always executed, but I had to try multiple times before it worked. @uGoMobi, @dzhongxu |
|
Thanks again @jerone ! I changed the title again... from broken to buggy. Not sure if that PhotoSwipe demo is a good reference, because I would have to see their code if they modify anything. But if swipe works better on that demo with JQM 1.0rc2 than with latest code we should check if this is a regression. |
|
After testing a couple of swipe apps. Even In old version, the swipe is 1.1.1 is buggy. Check this one: The 1.2.0 is also buggy. Check this one: On Sat, Jan 26, 2013 at 1:48 PM, Jasper de Groot
|
|
Hi Jerone, Have you fixed the bug? I met a difficulty to change the width of the panel. I simply set the width Thanks a lot? David On Sat, Jan 26, 2013 at 1:48 PM, Jasper de Groot
|
|
testing on http://jsbin.com/uzaret/891 swipe works perfectly and very responsive on all devices test this includes. |
|
Swiping is not working properly when we use Jquery Mobile on Android and Windows devices. Swiping is not smooth or sometimes it does not work at all. $(document).off('swipeleft swiperight','.test') swipe(event); Please help. And, what is the problem in JQM, even it is not working on Samsung galaxy S4 native browser. Is there any easy way to achieve this. This is not panel Swipe. This is swipe of a div section in a page. Am using jqm 1.3.1. If there is any fix, please let me know how should i incorporate this fix. |
|
I am also noticing very inconsistent swiping behavior on my android device (Galaxy Nexus) running Chrome mobile. Swiping almost always takes 2-5 attempts before the event finally triggers. I even noticed this behavior on the jquery mobile swipe demo page: http://jquerymobile.com/demos/1.3.0-beta.1/docs/demos/swipe/newyork.html the swiping is 100% consistent and smooth on my iOS test devices such as an iPhone 4. |
|
@agentfitz you are trying an old beta version on a demo thats not something thats actually part of the library to test please try the jsbin in my previous comment |
|
Hi there, thank you for the response. I just visited the page referenced in your post: http://jsbin.com/uzaret/891 But I'm not quite sure what the demo is. I tried swiping on the page and nothing happened. I then drilled down on jquerymobile.com/test and went to the demo showcase where I eventually found the "swipe to navigate" and "swipe to delete list item" demos. I wasn't able to get either of them to behave as I expected using swiping. Did I go to the wrong place? |
|
@agentfitz on that page simply swipe left or right and it throws an alert "swipeleft" or "swiperight" just tested on additional devices |
|
I understand Alexander. I was on 1.3.1 and the swipe was misbehaving, but when I looked at the source on your demo page and switched my app to the "latest" jquerymobile code, the swipe worked perfectly. Being in a pre-release state though, it did break some other stuff on me, such as formatting of controlgroups and such. Anyway, really pleased this will be fully addressed in an upcoming release! Thank you for your help. |
|
My team of engineers and I have come up with a proof-of-concept shim that provides a workaround for this issue. https://github.com/TNT-RoX/android-swipe-shim |
|
Shim is updated : https://github.com/TNT-RoX/android-swipe-shim |
|
Chrome 36 has resolved this issue for me, anybody else? |
|
@simonpapworth6742 yes they changed their thinking again on this. Talked with the head of web input at google a bit about this today and they are moving towards synchronous event processing in chrome for touch and scroll and have gone back on the idea of touch cancel. This fixes this problem in chrome. |
|
Note that prior to Chrome 36 the recommended way to address this problem is to check the direction of movement on the first touchmove event and decide based on that whether to call preventDefault(). I.e. if the touchstart->touchmove distance is primarily horizontal than preventDefault the touchmove to continue to get events and trigger a swipe. If it's primarily vertical then don't call preventDefault and you'll get scrolling instead. Many sites follow this pattern, and it's sometimes necessary on browsers other than just Chrome (eg. in Safari if horizontal scrolling is possible, and now in IE mobile if you're using touch events instead of pointer events, possibly also in Firefox). In Chrome 36+ as you've discovered you can use 'touch-action: pan-y' to make this simpler (although you still have to be careful to handle events only in the horizontal direction). You may also get away with handling the events without calling preventDefault or using touch-action, but it's probably not going to do exactly what you want in all cases. Eg. try swiping horizontally then changing directions and moving vertically - once you've started handling the swipe you probably don't want to allow vertical scrolling anymore, right? |
|
@RByers we only support horizontal swipe. Scrolling during swipe in the vertical direction we really are ok with either way and would prefer to leave this up to the devs where possible since this is just a generic event like click. so if it should block scrolling or not would depend on the developers specific use case for the event. This is why the touchcancel event handling here was troublesome it forced us to pick scrolling vs swipe even when the desired effect had no need to block but may just be recording that the event occurred. In general in apps made with jQuery mobile horizontal scrolling does not exist and would not be desirable this means that touch-action did fix this issue for the majority of situations. However the behavior in Chrome 36+ allows us to once again avoid making these decisions for the developers and just provide a generic event as we intended. @RByers Thanks for sharing the background from the Chrome team! |
|
Great, that's exactly why I pushed on this change - I'm glad it has worked for you! Note that most browsers still require you to make some choice between scrolling and event handling - eg. even in Chrome 36+ if active scrolling actually occurs (i.e. it is scrollable horizontally) we'll start throttling the touchmove events to ensure scrolling remains smooth. In Safari once scrolling has started you won't receive the touch events at all. But the key thing here is that in both cases it depends on scrolling actually occurring - if the page doesn't scroll horizontally then you'll get a reliable event stream. FWIW I just wrote a demo of the simple scenario (where relying on preventDefault is OK) here: https://plus.sandbox.google.com/u/3/+RickByers/posts/Ad5wGCceU2e |
|
Hi Rick, Thank you, Chrome 36 did arrive 24 hours later (I had no Idea that it was coming) and JQuery Mobile Swipe is working again, and luckily for me touch events are handled by JQM for me mostly. Also thank you for your “RE: Web facing change PSA: touch scrolling will no longer send touchcancel in Chrome 35” email, I am today looking at Touch Cancel to see if JQM does correctly use it. Again thank you SImon From: Rick Byers [mailto:notifications@github.com] Note that prior to Chrome 36 the recommended way to address this problem is to check the direction of movement on the first touchmove event and decide based on that whether to call preventDefault(). I.e. if the touchstart->touchmove distance is primarily horizontal than preventDefault the touchmove to continue to get events and trigger a swipe. If it's primarily vertical then don't call preventDefault and you'll get scrolling instead. Many sites follow this pattern, and it's sometimes necessary on browsers other than just Chrome (eg. in Safari if horizontal scrolling is possible, and now in IE mobile if you're using touch events instead of pointer events, possibly also in Firefox). In Chrome 36+ as you've discovered you can use 'touch-action: pan-y' to make this simpler (although you still have to be careful to handle events only in the horizontal direction). You may also get away with handling the events without calling preventDefault or using touch-action, but it's probably not going to do exactly what you want in all cases. Eg. try swiping horizontally then changing directions and moving vertically - once you've started handling the swipe you probably don't want to allow vertical scrolling anymore, right? — |
|
Thank you From: Alexander Schmitz [mailto:notifications@github.com] @RByers https://github.com/RByers we only support horizontal swipe. Scrolling during swipe in the vertical direction we really are ok with either way and would prefer to leave this up to the devs where possible since this is just a generic event like click. so if it should block scrolling or not would depend on the developers specific use case for the event. This is why the touchcancel event handling here was troublesome it forced us to pick scrolling vs swipe even when the desired effect had no need to block but may just be recording that the event occurred. In general in apps made with jQuery mobile horizontal scrolling does not exist and would not be desirable this means that touch-action did fix this issue for the majority of situations. However the behavior in Chrome 36+ allows us to once again avoid making these decisions for the developers and just provide a generic event as we intended. @RByers https://github.com/RByers Thanks for sharing the background from the Chrome team! — |
|
It's nice that Chrome 36 fixed this, unfortunately there's a lot of old versions of Android out there with Webviews that contain this bug, so it still affects Cordova/Phonegap apps running on older devices. |
|
or give Crosswalk a try |
|
Crosswalk's great but has its cons too: ~20Mb additional size on the APK and the need to build a separate package for x86 and ARM |
|
@dpa99c but i've tried hammer.js when the issue was reported and it didn't work... There is a new version with this fix? |
|
@Carlos487 I'm using v2.0.4 of hammer with Cordova 3.1.0 and JQM 1.4.5 |
|
@dpa99c I have a cordova 3.5 app with jquery mobile 1.3.2... I'm gonna try the new hammer.js thanks for the advice |
|
Still seeing this problem with an up-to-date S5 (AT&T) running Android native browser and Android 4.4.2. Not surprisingly angular ng-swipe-left and ng-swipe-right are also effected. I did notice a discrepancy in the user-agent strings between Chrome and Native Browser on this device: So apparently an up-to-date S5 is running Chrome 28 as the rendering engine in it's default browser? Note that remote debugging in the native browser seems to have died when Android switched from Apple's rendering engine to Chrome. Unfortunately S5 is the most popular Android out there and most people still use the big Internet button by default. So even though this is Google/Samsung's problem, it's our problem. Can anyone give me a straightforward monkey patch to get some kind of swipe to work on the old Chrome rendering engine? Edit: I see the ez-shim above by @TNT-RoX . I am going to try that.* Edit edit: no dice. I can only get the "swipeLeft" and "swipeRight" events to fire (using test.html) on desktop chrome - but not on either the Native Browser or Chrome on the device referenced above. Seems like el.onscroll doesn't fire at all on those browsers on the test app. |
|
Want to give an update here that i have been talking to @jtangler the creator of hammer.js for about 6 months about the future of Hammer.js and interoperability with jQuery Mobile. I can now say that i have officially taken over Hammer.js and am leading this project as well jQuery Mobile and we are looking into completely replacing jQuery Mobiles gestures with Hammer.js we cant say any thing concrete on this yet but it is likely we will be going in this direction. |
|
@arschmitz - do you have any idea if hammer.js horizontal swipe works better than jQuery Mobile or Angular swipe on Android native browser? I will give it a try on Monday when I have access. |
|
@jackspaniel yes i believe it does. It allows use of |
|
Hmm. Well if this is what creating your own proper swipe event looks like, that might be a little out of scope for us on this project. ;) I tried hacking around with that to get it to work on the latest Android native browser, and there's some pretty intense calculations and synchronicity going on. |
Fixes swipe events for all pixel densities. This is a partial fix for some swipe related issues. Ref jquery-archivegh-5534 closes jquery-archivegh-7431
|
Android 5.2 Galaxy S5, swipeleft works no problem, however, swiperight is buggy a lot |
|
Still having problems with that on Samsung Galaxy S4, Android 4.4.2. |
and others
A panel should be closed when users swipe left or right. But this function does not work in Galaxy S1 and S3 for 1.3.0 beta.
The text was updated successfully, but these errors were encountered: