search

jquery-archive / jquery-mobile

jQuery Mobile Framework
https://jquerymobile.com
Other
9.68k stars 2.4k forks source link

swipe is failing on android #1746

Closed AlexandreBernard closed 12 years ago

AlexandreBernard commented 13 years ago

swipe events are causing troubles on android.

in some cases i'm still trying to understand the browser is freezing for a long time (or forever) after firing a swipe event

sorry for the lack of details. i'll post more if i find something

mdhari commented 13 years ago

Can you output the adb logcat. I suspect it has to do with this warning: 05-31 14:36:37.818 23725 23725 W webview : Miss a drag as we are waiting for WebCore's response for touch down. On my Droid X, its fine, but online I read on HTC phones, it can crash the device.

AlexandreBernard commented 13 years ago

of course i forgot to tell which phone it was : the winner is HTC desire can't test again until wednesday but i felt there was problems like this with touch events on this phone, so your hypothesis make sense to me

Camelcase commented 13 years ago

Yeah, same problem on my motorola Charm (Android 2.1). total swipe failure. It would be great if this could somehow be resolved.

toddparker commented 13 years ago

Hey all - we don't yet have a test device with this installed so I don't know what's up with Swype but since it's sort of a system extension (yes, I know it's pre-installed sometimes), I just don't know if it has some rough edges with the OS. I think if anyone can point to a specific JS or CSS thing we're doing, we'd be happy to consider making a tweak to support this better. It's just a bit low on the priority list right now so help is appreciated.

pauldaly commented 13 years ago

Swype Droid Jquery Mobile data-role= page

I am having the same or similar issue with Swype not working on my droid. I have narrowed my issue to the data-role="page" element. Any field within this element affects Swype. Removing data-role="page" allows swype to function as expected.

I understand this is low on the priority list but Swype is a significant reason people are switching to droid and why they have about 50% of the smart phone market. I can code around the issue but would love to see this raised higher on the priority list.

Cheers Paul

hanami279 commented 13 years ago

So, I have exact same problem with swipe feature on Verizon HTC Droid Incredible (Android 2.2). Sometimes it works, but sometimes may freeze the browser.

PS: my phone fails with this sample: http://www.coldfusionjedi.com/demos/artbrowse/

UPDATE: This problem only happens with swiperight or swipeleft event. So 'swipe' event works fine on my phone

adriancd commented 13 years ago

Swiperight and swipeleft not working in Galaxy S with Android 2.3.3. Fine in iphone

joylon commented 13 years ago

Swiperight and swipeleft not working well on lenovo lepad ,android system: Android 2.3,

the Follow is the Adblog;

10-25 01:02:50.714: DEBUG/WifiHW(1100): >>> wifi_send_command, cmd= DRIVER RSSI-APPROX 10-25 01:02:50.722: DEBUG/WifiHW(1100): <<< wifi_send_command, cmd= DRIVER RSSI-APPROX 10-25 01:02:50.722: DEBUG/WifiHW(1100): >>> wifi_send_command, cmd= DRIVER LINKSPEED 10-25 01:02:50.722: DEBUG/WifiHW(1100): <<< wifi_send_command, cmd= DRIVER LINKSPEED 10-25 01:02:51.879: WARN/webview(22501): Miss a drag as we are waiting for WebCore's response for touch down. 10-25 01:02:53.722: DEBUG/WifiHW(1100): >>> wifi_send_command, cmd= DRIVER RSSI-APPROX 10-25 01:02:53.730: DEBUG/WifiHW(1100): <<< wifi_send_command, cmd= DRIVER RSSI-APPROX 10-25 01:02:53.730: DEBUG/WifiHW(1100): >>> wifi_send_command, cmd= DRIVER LINKSPEED 10-25 01:02:53.730: DEBUG/WifiHW(1100): <<< wifi_send_command, cmd= DRIVER LINKSPEED 10-25 01:02:54.558: WARN/webview(22501): Miss a drag as we are waiting for WebCore's response for touch down. 10-25 01:02:54.699: DEBUG/skia(22501): Loading ARM decoder... 10-25 01:02:54.707: DEBUG/skia(22501): Loading ARM decoder... 10-25 01:02:54.707: DEBUG/skia(22501): Loading ARM decoder... 10-25 01:02:54.714: DEBUG/skia(22501): Loading ARM decoder... 10-25 01:02:56.738: DEBUG/WifiHW(1100): >>> wifi_send_command, cmd= DRIVER RSSI-APPROX 10-25 01:02:56.738: DEBUG/WifiHW(1100): <<< wifi_send_command, cmd= DRIVER RSSI-APPROX 10-25 01:02:56.738: DEBUG/WifiHW(1100): >>> wifi_send_command, cmd= DRIVER LINKSPEED 10-25 01:02:56.738: DEBUG/WifiHW(1100): <<< wifi_send_command, cmd= DRIVER LINKSPEED 10-25 01:02:56.980: WARN/webview(22501): Miss a drag as we are waiting for WebCore's response for touch down. 10-25 01:02:59.746: DEBUG/WifiHW(1100): >>> wifi_send_command, cmd= DRIVER RSSI-APPROX 10-25 01:02:59.746: DEBUG/WifiHW(1100): <<< wifi_send_command, cmd= DRIVER RSSI-APPROX 10-25 01:02:59.746: DEBUG/WifiHW(1100): >>> wifi_send_command, cmd= DRIVER LINKSPEED 10-25 01:02:59.746: DEBUG/WifiHW(1100): <<< wifi_send_command, cmd= DRIVER LINKSPEED

best regards joylon

toddparker commented 13 years ago

Hi all - is this happening in the browser or in a webview within an app or both? Can you create a minimal test page using latest, template here: http://jsbin.com/aciteb/edit

adriancd commented 13 years ago

Browser, with just the basic code.

$('#divID').live('swipeleft swiperight',function(event) { }

toddparker commented 13 years ago

@adriancd - thanks, but can you use the template to save a test page we can use to both diagnose and confirm when we fix this? Link above.

pauldaly commented 13 years ago

I am happy to help work through this issue. I do not see an issue with Swype on the template but the JQM version is different that what I am using. My site currently uses jqm-1.0b2. I will upgrade to 1.0rc2 and see if the problem is fixed. The template is at: http://jsbin.com/aciteb/4

pauldaly commented 13 years ago

Sorry, I am mixing issues. My issue is Swype, not swipe. Still willing to review and help resolve...Swype

pauldaly commented 13 years ago

moving my Swype discussion to https://github.com/jquery/jquery-mobile/issues/637

cewen commented 12 years ago

@toddparker - I am seeing this issue on the HTC Droid Incredible as well. "swipeleft" and "swiperight" events cause the browser to hang up until (it seems) the user performs a click or touch on the screen. Even then, it seems to hang momentarily. Has any progress been made on a fix for this issue?

Seriously considering abandoning jQuery Mobile as it has provided more than its share of headaches.

jblas commented 12 years ago

Reading this thread it is obvious to me that folks are talking about 2 different things.

@AlexandreBernard, when you filed this issue were talking about Android's "swype" keyboard extension? Or were you talking about the jQuery Mobile custom events swiperight/swipeleft?

@cewen the problem we have is that folks always chime in and never give us a sample or steps to reproduce their problem. If we had an example that clearly illustrates the problem, as well as info on what type of device you are seeing this on, what version of the OS you are using, and info on the Browser/PhoneGap/WebView viewer you are using, then we can work on our end to try to reproduce and figure out what is going on. Have you filed issues regarding your other headaches?

cewen commented 12 years ago

@jblas Here is more detail about my issue, which sounds exactly like what @hanami279 was experiencing in September:

Device: Verizon HTC Droid Incredible OS: Android 2.2 Browser: Webkit 3.1

I have a basic carousel HTML structure set up on my page, in which an absolutely positioned DIV (.product_carousel_slider) is meant to slide around inside of a relatively positioned DIV, when the user triggers a "swipeleft" or "swiperight" event.

$('.product_carousel_slider').bind('swipeleft swiperight', function(e){ e.preventDefault(); xProductCarousel.moveCarousel(e.type); }

(inside of xProductCarousel object:) moveCarousel:function(sEventType){ var scrollAmount = xProductCarousel.nViewportWidth; this.nCurrentPosition = (sEventType === 'swipeleft') ? this.nCurrentPosition - scrollAmount : this.nCurrentPosition + scrollAmount;

this.nCurrentPosition = Math.min(0, this.nCurrentPosition);
$('.product_carousel_slider').css('left', this.nCurrentPosition+'px');

}

This works as expected on other Android devices I've tested, including the Kindle Fire, the HTC Inspire. Also works well on the iPhone. The problem is that on my test HTC Droid Incredible, the browser freezes, and only after the user touches/clicks in desperation does the browser slowly come back to life.

DracoBlue commented 12 years ago

The issue seems to be the e.preventDefault();, if I remove that in my test case: it works. But since we don't want to have the default behaviour (scrolling the page up/down), this is not a solution :(.

cewen commented 12 years ago

@DracoBlue Thanks, good to know. At least with this knowledge, we can try to prevent the default behavior in another manner ie. "return false" or some other hacky method.

gboom commented 12 years ago

For someone who's breaking their head with this, try this, this worked for me:

For literally every touch, i got the warning message "Miss a drag as we are waiting for WebCore's response for touch down.". Though it was not too slow on my Samsung Galaxy Y running Android 2.3, it broke my friend's HTC Wildfire running Android 2.1. Broke in the sense, each touch took 5 seconds to process.

I was using PhoneGap 1.4.1 with one of JQuery Mobile 1.0.1 / 1.0 / 1.0rc3 and iScroll.

Fix:

In iScroll.js, the method onBeforeScrollStart had the only e.preventDefault() call. I deleted this. And then bingo, the warning message frequency was reduced to maybe 1 per 10 touches.

In JQueryMobile 1.0rc3, I deleted this section (since I was purely using iscroll, i wasn't worried of any scroll events breaking, and happily, nothing broke for the scope of my app)

                  if (activeDocHandlers[ "touchstart" ] === 1) {
                $document.bind( "touchstart", handleTouchStart )
                ...
                           ...
                .bind( "scroll", handleScroll );
           }

Doing these removed all traces of that warning from my app. Now i see 1 such warning for every 50 touches. This i believe is generated by the Galaxy Y itself (Even in other apps, touch fails rarely, probably a limitation of the device).

Well, I haven't had a chance to test on HTC yet. Will update this thread when I do.

Koniak commented 12 years ago

Binding swipeleft or swiperight causes scrolling to hang every 1 in 2 to 1 in 5 normal scrolling. Nothing happens from touchstart to touch end. When releasing the finger and trying again it normally work for a few times. At release LogCat show the following message: Miss a drag as we are waiting for WebCore's response for touch down.

Please observe that you do not need to be on the page that has bound the swipe event, it just have to have been bound earlier. All JQM pages then have the same problem when scrolling long pages.

I have replicated the problem in the follwoing environments.

(Android 2.3 Emulator , HTC Desire HD 2.3 do NOT have this problem)

To me it would seem this is an Android 4 problem?

Koniak commented 12 years ago

Have made an example at JSbin: http://jsbin.com/akecos/2

Have replicated the "scroll freeze" problem with code above in the following environments:

Please note the browser option, which makes it easy to test through jsbin.

santaduda commented 12 years ago

I have been facing the issue too. I get a drag miss warning but it works in android 2.2 and 2.3 but it does not work in android versions > 2.3.5.

If I add a ontouchmove listener and e.preventDefault() the swipe left right works fine but if the page has a scrolling data the page does not scroll up and down.

rascalking commented 12 years ago

I repro'd this on a Galaxy Nexus using Chrome 18, JQM checked out from git.

This seems to be an android-specific webkit bug. I took Koniak's code from his jsbin example, and threw some console.log statements into the swipeleft code to log when our touchstart, touchmove, and touchend handlers got called.

When the freeze would happen, I would see the touchstart and a couple touchmoves, then nothing. I'd wait a while, then try scrolling, which would show a new touchstart, lots of touchmoves, and then two touchends.

An answer on a stackoverflow question (http://stackoverflow.com/a/11613327/116800) pointed towards a couple bugs filed against android webkit/webview (http://code.google.com/p/android/issues/detail?id=4549 and http://code.google.com/p/android/issues/detail?id=19827). In the 4549 bug, a developer from google claims that it was fixed in Jelly Bean native browser, but someone in the 19827 bug says that it wasn't actually fixed.

Long story short, if touchend isn't firing, swipeleft isn't going to work.

toddparker commented 12 years ago

Thanks @rascalking for testing and digging up that info. Seems like this bug probably can be closed if this is just an Android bug. If the events aren't there, we can't do anything on our end. Thoughts?

rascalking commented 12 years ago

That'd be my suggestion, yeah.

toddparker commented 12 years ago

Closing as an Android bug we can't work around. We can re-open if someone has suggestions on alternate ways to workaround these bugs.

salamanders commented 11 years ago

Ran into this with the 1.4 alpha. I had the following code, that was generating errors. Had to remove it on Android.

$('#article').on('swiperight', function(e) {
    $.mobile.changePage('#home', {reverse: true, changeHash: false});
  });

"Miss a drag as we are waiting for WebCore's response for touch down."

It may be useful to add to the docs that this breaks on various android devices? Or perhaps generate a console warning when you are using swipe on Android? Anything to warn developers before they get the same keyboard imprints on their forehead that I have.

arschmitz commented 11 years ago

just a note starting in 1.4 swipe does not wait for touch end and triggers after touch move meets requirements instead but from the sounds these are getting cut off as well by this bug