Taphold fires tap event as well

[nicolasgoutaland]

Hi all,

I've just upgraded to JQM 1.1.0 and the behaviour with tap/taphold seems to have been modified.

Following code worked on JQM 1.0.1, firing only taphold. With JQM 1.1.0-RC1, taphold is fired first, followed by tap.

$(".projects-container").bind('tap', function(){ console.log("tap"); }); $(".projects-container").bind('taphold', function(){ console.log("taphold"); });

Am I doing something wrong, or is it a bug ?

Tested on Chrome desktop and iOS 5.1, problem appear on both.

Thanks

[johnbender]

@gougou1

Looking into it now. My local testing confirms this is an issue. In case I get pulled away:

http://jsbin.com/arujin

[johnbender]

@gougou1

In the process of bisecting it appears that this is still the case in 1.0.1 which makes me think that I've misunderstood the issue:

http://jsbin.com/arujin/2/edit

That one points at the cdn for 1.0.1 and the output I get when I click and hold and then release is:

taphold
tap

That's not to say that it should necessarily behave this way just that it's been this way since 1.0.1. Can you confirm?

[nicolasgoutaland]

Hi,

I confirm, the output is the same on 1.0 and 1.0.1.

In fact, in my taphold event, I performs a call to the simpleDialog2 plug-in

http://dev.jtsage.com/jQM-SimpleDialog/demos2/

lastSelectedProject.simpledialog2({ 'mode' : 'button', 'headerText' : 'Information', 'buttonPrompt' : "Select an option below for '" + lastSelectedProject.children(".projects-title").text() + "' project", 'zindex' : 99999, 'buttons' : { ....

So my guess is that in 1.0.1, the plug-in disrupt the event so when taphold is called, next event is ignored, and with 1.1- RC1, the event is still delivered. So, i didn't notice the problem before upgrading to JQM 1.1.

Is it possible that the plug-in disrupt events delivery ?
Can you confirm that you can reproduce the problem with simpleDialog2 ?

About the behaviour, I think that is a taphold event is delivered for a component, a tap event should be dismissed to prevent such problems, no ?

Thanks for your help

[jdtommy]

We have this same problem when the same tag has both tap and taphold bindings on it. I can get around it for android, but ios actually will fire the tap on a long press so I am not sure how to get around that one. Any word on a work around or if this will change in the future?

[davidmaxwaterman]

I did a jsfiddle to demo this issue: http://jsfiddle.net/TYDN8/1/ but it probably doesn't show anything more than the jsbin example.

I wonder if there is any prospect of a fix for this? I suppose the w/a is to remove the tap handler when the taphold is triggered?

[rmantilla26]

Any solution for to bug ?

[jaspermdegroot]

#4900 and #4738 are closed as duplicated.

Changed the title of this ticket (initial title: "Problem with tap/taphold on same target with JQM 1.1.0 RC1")

[arschmitz]

After some discussion this morning we have decided that we are not going to change this behavior it has been link this since pre 1.0 and based on the name tap hold it is expected it will still fire the tap event. tap hold is a special version of tap. we are going to better document this behavior. I'm closing this as wont fix.

[realtebo]

and so... ? now 1.3.0 has been released, and the 'unexpected behaviuor' is still here, and in the api doc there is no mention about this, and there is not workaround .

How can we distinguish a tap from taphold ?

If I check event.type into tap event, it's 'tap', so I've not way to understand if a tap is a side effect of taphold of if it's a real simple tap.

Help us !!!!

[cfjedimaster]

I'd agree that this should be documented as well. Also, there should be at least one example of how developers can handle this. Ie, if I want to do X for tap and Y for taphold, I'd expect the jQM docs to show an example of how I could ensure that taphold doesn't run X accidentally. (Because frankly, that's what users will see - something unexpected.)

[IHNEL]

Why this bug still alive at JQM 1.3.0? It's a common and major bug.