You can clone with
HTTPS or Subversion.
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.
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.
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.
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.
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.
scratch that it does not matter whether external or not, happening all over the place
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, 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
Nice catch, I was using b1. Switched to the nightlies and $.mobile.useFastClick = false is now working.
We switched back to using click instead of vclick for links and removed the useFastClick option in the latest. This is now fixed.
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.
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.