Single tap triggers two actions, especially in Android B1 #1925
Comments
|
Thanks for the roundup. We're actually having a call today to hash out a solution to this. It's related to some recent changes to our event system for handling touch and mouse events. There are some really tricky browser bugs we're trying to normalize and workaround. Stay tuned. |
ghost
assigned 
|
I spent a bit of time looking into similar issues with our app and found that increasing $.vmouse.clickDistanceThreshold to 25 helped us quite a bit. Ymmv. |
|
We just landed a big change to these events, can you test with latest? |
|
I've run some initial tests with the latest and most of the symptoms in this area have gone away. Your check-in seems to be a big help. Thank you! There is, however, still one circumstance where I can reproduce this problem in our app. I will try in the next couple of days to reduce this case to a simple test case app that I can give you. Unfortunately, tomorrow I have to close a release cycle and help a client with a major presentation, so it will probably be early next week before I can do that. Briefly, I have a select that pops up such that the last item occludes a text area. An on change event changes the display attribute of a number of hidden fields, one of which is a text input that appears under the tapped on list item. On an iPhone the virtual keyboard flashes on and off screen, as if either the text area that was under the pop-up or the text input that appears at that point was clicked in. It happens only some times and a quick light tap seems to be able to avoid it. There are many JQM "pages" in the app and several controls on this page. I need to pare it back to be manageable. Many thanks. |
|
Thanks for the quick turnaround on trying to address the click issues with beta 1! So, with the latest and projected beta 2 version is the recommended approach going forward to bind to click instead of vclick for custom event handlers? Custom event handlers appear to still be invoked when binding to either, I'm just now wondering which is the most appropriate to use? |
|
I've reduced my test case to a moderately simple file that will sometimes, but not always exhibit the problem I've been seeing. To reproduce it, go to using an iPhone. Tap on the "Level" selector, then tap on an option that occludes either the "Text" or "Event" text input areas. Light/Fast taps seem to work almost all of the time. Longer taps will act sometimes act as if they are sent to multiple controls. For instance, the virtual keyboard may appear or may flash on and off screen. I wish I had something that reproduced it more reliably, but as it looks to be a race condition, it is intermittent by nature. Again, this is much better since the latest dropped the vclicks. |
|
This should be fixed in Beta 2. We can re-open if you're still seeing this. |
|
Thank you for reopening it, Todd. I'm having (marginally) less trouble in Beta 2 than Beta 1, which in turn was markedly better than the Alphas, but it is still occurring. My testbed for this remains http://test.eldacur.com/JQM/bug-2.html which has been updated to loaf Beta2. As before, to reproduce the bug, connect to the test page from an iPhone, tap on the "Level" selector, then tap on an option that occludes either the "Text" or "Event" text input areas. Light/Fast taps should work. Longer taps will act as if they are sent to multiple controls. |
|
Still seeing this issue with both iOS and Android devices. We have a floating footer that stays on the bottom of your screen when you scroll. If you click a button on the footer it will also trigger w/e event is attached to the element underneath the footer. |
|
You are seeing this with Beta 2? |
|
I'm assuming from the other 2 bugs filed by you ... that you are using Beta 2 ... can I see an example of this problem? Or can it be reproduced with one of our doc pages? |
|
I'm not Joster, but I am seeing it in Beta 2, as shown with my example code at http://test.eldacur.com/JQM/bug-2.html . |
|
Yeah I have a fix in mind for that particular bug. The problem with inputs/textareas is that they react to mousedown to get focus. We're processing the select choice made by the user on touchend which occurs before the fake mouse events are dispatched ... and even then we are only usually concerned about blocking any fake mouse click that happens. The only way for us to fix this problem, is to avoid it by moving our actions back to the "click" event. Unfortunately this means a 300 millisecond pause between touch and action on some platforms like iOS ... that said, it's better to have expected versus incorrect behavior. |
|
Great. That makes perfect sense to me. |
|
Just a thought... Not sure if it would work but what about using zindex or something to get the top most element and apply the tap to that element only? |
|
Short of calling preventDefault() on a touchstart event, we have no control of what the browser calculates as the target of the synthesized mouse events that follow touchend are. The only reliable cross-implementation way to avoid problems is to execute actions on the mouse events (click) ... that way things like the thing being clicked on disappearing before mouse events are dispatched, don't happen. Checkout this article that tries to spell out a few of the gnarly problems: http://blogs.adobe.com/adobeandjquery/2011/03/07/the-current-state-of-touch-events/ |
|
@jblas I've tried vclick and everything for the footer nav bar. it doesn't seem to be an issue inside of chrome while testing but inside iOS and Andriod it is still a problem. Not as much as using tap but still everyonce in awhile it will still trigger the event below it. Setting all my taps to vclicks actually prevents the navbar from working at all. |
|
Right, on touch devices vclick maps to the touchend, which is BEFORE the browser dispatches the synthesized mouse events ... hence the problem. The problem is that the targets of the touch events and the synthesized mouse events don't necessarily match. In the select case on a touch device, the item on the select menu is chosen on vclick (touchend), but part of the select action is to dismiss immediately (before the mouse events are dispatched). When the browser finally fires the mouse events, it does some heuristics, mainly position related, to figure out what the target should be, since the select menu is gone, it chooses whatever is there, in this case its a text input (textarea). |
|
@jblas My issue isn't with the select box and text area but with the footer and listview behind it. It seems that about 1 out of 15 touches triggers the footer nav bar event then the event for the list item underneath the footer nav bar. I wasn't able to duplicate it on the demo site because you guys had it going to different html pages while we are having it go to different pages via hash. |
|
It's still related to the touch and mouse event target mismatches. Remember above when I said heuristics? Each vendor has their own way to figure out what point a fat finger-print is supposed to represent ... unfortunately in some implementations they factor in markup hierarchy, and it also seems that the coordinates calculated and used in the events are different. A while back when I first started looking into these problems, I put together some test pages that demostrated the problems we were up against: http://webpro.host.adobe.com/people/jblas/research/events/touch-and-mouse.html The last example there was especially worrisome since you could tap on something and the touch event would have the target you clicked on, but the mouse events that were fired were for something 200px away that didn't intersect with what you touched. |
|
Is there a solution? Sent from my iPhone On Aug 24, 2011, at 4:46 PM, jblas
|
|
I mentioned the solution earlier ... perform the action on the mouse events instead of the touch events. That way you don't factor in the browser's potential event target mismatches. Unfortunately this also means that action response times seem a bit sluggish ... roughly 300ms. Because of this problem we've had to back off of our aggressive fire off actions on vclick approach that we started in alpha 4, which is unfortunate since it made things very responsive. The bottom line is that trying to treat touch events like mouse events only works well when you have an environment where things don't overlap. |
|
@jblas Thanks. I set all my taps to vclick and sent it to qa. They stated they are still getting the double events but not as frequent. |
|
Setting everything to vclick doesn't work. Will setting just the footer to vclick work or will the listview need to be a vclick as well? On Aug 24, 2011, at 4:54 PM, jblas wrote:
|
|
@jblas Would you like the original we had with the tap event or the one with the vclick? It seemed moving it to vclick reduced the frequency of it happening but it still happened. |
|
Either will work ... it's just simple string change to switch between the two right? I just need to see what controls are involved, or if you're tapping directly on the footer? The original markup/setup would be good. |
|
I'm moving the priority of this down, but keeping it open because Kin landed a fix for this and it seems to be relegated to a very specific use case now that is just the typical target mismatch stuff. |
|
Yes, I created a copy of my bug test that links to Beta 3, named boringly enough, http://test.eldacur.com/JQM/bug-3.html which works substantially better than bug-2 which uses Beta 2 and in turn worked better than the original bug. You are definitely converging on this one and Beta 3 is usable for our production app. I can still get it to misbehave, but I have to really try, I completely agree with down grading this from Blocker to High. Thank you all for all the hard work work. |
|
I seem to be able to trigger this fairly consistently as well. I've got a html file with 3 pages, Main, Notifications and Info. The main has a footer bar with a click event (I've tried with tap as well). Tapping/clicking the footer should slide in the notifications page, which contains a listview, any item in the list should in turn show the Info page. Clicking on the footer will 2/3rds of the time trigger the listview item in the Notifications page as well. This seems to be a problem more with my android 2.1 phone than the iPhone simulator but both can trigger it. This is with Beta 3 |
|
Do you have a sample we can use to reproduce the problem? |
|
http://www.jdwilkins.co.uk/jqmtest/ 3 pages - first is home screen, tapping footer should slide in notifications page, selecting item from notifications page should bring up 'unavailable' page. I've been experimenting with different events on index.html line 55 With a 'tap' event to show notifications page
With 'vclick' event - same as for tap With 'click' event, Chrome on desktop - works Thanks |
|
Just for the record. I concur on closing. Thank you. |
|
After 2 years it remains the same... |
|
Using jquery-mobile 1.3.2 |
|
Hey any ideas? Is there a workaround? |
We've been seeing a cluster of problems that appear to be caused by a single tap triggering more the one event. This could be related to the "Click triggers event from previous page" issues (#1904, #1769, and possibly #1879), if I understand those issues correctly. We've seen this happen in both A4 and B1, on both Android and iPhone. It is worse on Android than iPhone, and worse in B1 than A4. I suspect it is a timing issue that is worse with more overworked CPUs. That's just a guess.
The scenario that we see this most in is with a select element. The user taps the select and the select list pops up, covering other controls. The user taps one of the options in the select list, and both the event associated with that option and the control it occludes trigger. The most common of these is when a text or text area item is occluded. Quick light taps seem less likely to induce this. That could be an illusion.
The problem could be caused either by the select control being "transparent" to the tap and it being delivered twice or by the select list being pulled away with the finger still down, sending a second tap to the revealed control. The possibility that it is the latter is why I think it might be related to the "tap seen on both pages" or "back button double tap" type issues.
The text was updated successfully, but these errors were encountered: