New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Android multiple tap events fired across different pages with transitions disabled #1904

Closed
adambiggs opened this Issue Jun 22, 2011 · 11 comments

Comments

Projects
None yet
6 participants
@adambiggs

adambiggs commented Jun 22, 2011

I have transitions disabled because of Android's horrible CSS transition support. But now I'm seeing tap events firing on the first page, and then again on the second page.

To recreate this, set the default transition to 'none' and create 2 pages, each with a button in the same place. Make the first page's button change pages to the second page, then make the 2nd page's button alert something. What you'll see when you tap the first button is the 2nd page will load, and then the 2nd page's button will also get triggered...

What's going on here? Is the tap event being fired as well as the click event? I wasn't seeing this in a4.1.

@jblas

This comment has been minimized.

Show comment
Hide comment
@jblas

jblas Jun 22, 2011

Contributor

@adambiggs

Until we get this sorted out, if you search for the default setting of $.mobile.useFastClick and set it to false, it should restore the old behavior.

Contributor

jblas commented Jun 22, 2011

@adambiggs

Until we get this sorted out, if you search for the default setting of $.mobile.useFastClick and set it to false, it should restore the old behavior.

@robcaldecott

This comment has been minimized.

Show comment
Hide comment
@robcaldecott

robcaldecott Jun 23, 2011

I tried the fix and I still get the issue on Android. I am using the latest source and modified useFastClick directly in the defaults section of the js code. I still get clicks firing on the next page.

robcaldecott commented Jun 23, 2011

I tried the fix and I still get the issue on Android. I am using the latest source and modified useFastClick directly in the defaults section of the js code. I still get clicks firing on the next page.

@tbeseda

This comment has been minimized.

Show comment
Hide comment
@tbeseda

tbeseda Jun 23, 2011

I'm having a similar issue with transitions enabled, only with the back button:
On page A, navigate to Page B, navigate to C, tap back button, slide to Page B (where there is no back button), immediately/unwillingly slide to Page A.

tbeseda commented Jun 23, 2011

I'm having a similar issue with transitions enabled, only with the back button:
On page A, navigate to Page B, navigate to C, tap back button, slide to Page B (where there is no back button), immediately/unwillingly slide to Page A.

@trainiac

This comment has been minimized.

Show comment
Hide comment
@trainiac

trainiac Jun 23, 2011

Also having the problem with Android 2.3 where I tap a link on one page and then brought to the next page and the link in the same spot is being triggered. The link on the second page is a rel="external", not sure if that makes a difference.

trainiac commented Jun 23, 2011

Also having the problem with Android 2.3 where I tap a link on one page and then brought to the next page and the link in the same spot is being triggered. The link on the second page is a rel="external", not sure if that makes a difference.

@trainiac

This comment has been minimized.

Show comment
Hide comment
@trainiac

trainiac Jun 23, 2011

scratch that it does not matter whether external or not, happening all over the place

trainiac commented Jun 23, 2011

scratch that it does not matter whether external or not, happening all over the place

@adambiggs

This comment has been minimized.

Show comment
Hide comment
@adambiggs

adambiggs Jun 27, 2011

@jblas

I just went back to Android and tried setting $.mobile.useFastClick to false in the mobileinit event (placed before the jQM javascript file). It seems to have improved things slightly, but I'm still getting double events fired pretty regularly.

I should mention that this was also an issue with a4.1 but seems to be worse now (even with useFastClick set to false).

adambiggs commented Jun 27, 2011

@jblas

I just went back to Android and tried setting $.mobile.useFastClick to false in the mobileinit event (placed before the jQM javascript file). It seems to have improved things slightly, but I'm still getting double events fired pretty regularly.

I should mention that this was also an issue with a4.1 but seems to be worse now (even with useFastClick set to false).

@trainiac

This comment has been minimized.

Show comment
Hide comment
@trainiac

trainiac Jun 27, 2011

@adambiggs, do you have the latest update? There was an issue with setting the useFastClick option with the initial release of Beta that has since been fixed. See here #1916

trainiac commented Jun 27, 2011

@adambiggs, do you have the latest update? There was an issue with setting the useFastClick option with the initial release of Beta that has since been fixed. See here #1916

@adambiggs

This comment has been minimized.

Show comment
Hide comment
@adambiggs

adambiggs Jun 28, 2011

@metalculus84

Nice catch, I was using b1. Switched to the nightlies and $.mobile.useFastClick = false is now working.

adambiggs commented Jun 28, 2011

@metalculus84

Nice catch, I was using b1. Switched to the nightlies and $.mobile.useFastClick = false is now working.

@toddparker

This comment has been minimized.

Show comment
Hide comment
@toddparker

toddparker Jun 30, 2011

Contributor

We switched back to using click instead of vclick for links and removed the useFastClick option in the latest. This is now fixed.

Contributor

toddparker commented Jun 30, 2011

We switched back to using click instead of vclick for links and removed the useFastClick option in the latest. This is now fixed.

@toddparker toddparker closed this Jun 30, 2011

@adambiggs

This comment has been minimized.

Show comment
Hide comment
@adambiggs

adambiggs Jun 30, 2011

Just a thought - what if there was an option to enable useFastClick but completely disable the regular click events. I'm guessing this would break buttons in desktop browsers, but would be a perfect option for PhoneGap applications where this isn't a concern (and where it's more important to emulate native app responsiveness).

Not even sure if this would solve the issue though... just pure speculation.

adambiggs commented Jun 30, 2011

Just a thought - what if there was an option to enable useFastClick but completely disable the regular click events. I'm guessing this would break buttons in desktop browsers, but would be a perfect option for PhoneGap applications where this isn't a concern (and where it's more important to emulate native app responsiveness).

Not even sure if this would solve the issue though... just pure speculation.

@jblas

This comment has been minimized.

Show comment
Hide comment
@jblas

jblas Jun 30, 2011

Contributor

Hey Adam,

Using fastclick equivalents "vmousdown", "vmouseup", "vclick", etc. works fine on desktop because it directly maps to the native events. The problem with this stuff comes in to play on Touch devices ... specifically webkit based browsers where each vendor has to implement their own touch events. This leads to problems where touch events have DIFFERENT targets from the synthesized mouse events that follow ... this difference is what is causing the double tap/click issues folks are seeing.

We've found that the only way (today) to avoid those problems is to simply do our actions on the "click" event. We can give feedback on the virtual events (touch), but for reliability, we really need to fire the work off on the synthesized "click" event.

Contributor

jblas commented Jun 30, 2011

Hey Adam,

Using fastclick equivalents "vmousdown", "vmouseup", "vclick", etc. works fine on desktop because it directly maps to the native events. The problem with this stuff comes in to play on Touch devices ... specifically webkit based browsers where each vendor has to implement their own touch events. This leads to problems where touch events have DIFFERENT targets from the synthesized mouse events that follow ... this difference is what is causing the double tap/click issues folks are seeing.

We've found that the only way (today) to avoid those problems is to simply do our actions on the "click" event. We can give feedback on the virtual events (touch), but for reliability, we really need to fire the work off on the synthesized "click" event.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment