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

Taphold fires tap event as well #3803

Closed
nicolasgoutaland opened this Issue Mar 12, 2012 · 34 comments

Comments

Projects
None yet
@nicolasgoutaland

nicolasgoutaland commented Mar 12, 2012

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

@ghost ghost assigned johnbender Mar 13, 2012

@johnbender

This comment has been minimized.

Show comment
Hide comment
@johnbender

johnbender Mar 13, 2012

Contributor

@gougou1

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

http://jsbin.com/arujin

Contributor

johnbender commented Mar 13, 2012

@gougou1

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

http://jsbin.com/arujin

@johnbender

This comment has been minimized.

Show comment
Hide comment
@johnbender

johnbender Mar 13, 2012

Contributor

@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?

Contributor

johnbender commented Mar 13, 2012

@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

This comment has been minimized.

Show comment
Hide comment
@nicolasgoutaland

nicolasgoutaland Mar 13, 2012

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

nicolasgoutaland commented Mar 13, 2012

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

This comment has been minimized.

Show comment
Hide comment
@jdtommy

jdtommy May 15, 2012

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?

jdtommy commented May 15, 2012

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

This comment has been minimized.

Show comment
Hide comment
@davidmaxwaterman

davidmaxwaterman Sep 11, 2012

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?

davidmaxwaterman commented Sep 11, 2012

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

This comment has been minimized.

Show comment
Hide comment
@rmantilla26

rmantilla26 Dec 3, 2012

Any solution for to bug ?

rmantilla26 commented Dec 3, 2012

Any solution for to bug ?

@jaspermdegroot

This comment has been minimized.

Show comment
Hide comment
@jaspermdegroot

jaspermdegroot Dec 16, 2012

Member

#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")

Member

jaspermdegroot commented Dec 16, 2012

#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

This comment has been minimized.

Show comment
Hide comment
@arschmitz

arschmitz Dec 17, 2012

Member

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.

Member

arschmitz commented Dec 17, 2012

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.

@arschmitz arschmitz closed this Dec 17, 2012

@realtebo

This comment has been minimized.

Show comment
Hide comment
@realtebo

realtebo Apr 10, 2013

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 !!!!

realtebo commented Apr 10, 2013

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

This comment has been minimized.

Show comment
Hide comment
@cfjedimaster

cfjedimaster Apr 10, 2013

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.)

cfjedimaster commented Apr 10, 2013

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

This comment has been minimized.

Show comment
Hide comment
@IHNEL

IHNEL Apr 17, 2013

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

IHNEL commented Apr 17, 2013

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

@arschmitz

This comment has been minimized.

Show comment
Hide comment
@arschmitz

arschmitz Apr 17, 2013

Member

It is not a bug it is how the events work. if we were to prevent tap on taphold we would have to delay emitting the tap event until after we determined if it was a taphold needlessly delaying the event also this is not "unexpected behavior" this is the expected behavior and has been since pre 1.0 see my previous comment.

Member

arschmitz commented Apr 17, 2013

It is not a bug it is how the events work. if we were to prevent tap on taphold we would have to delay emitting the tap event until after we determined if it was a taphold needlessly delaying the event also this is not "unexpected behavior" this is the expected behavior and has been since pre 1.0 see my previous comment.

@cfjedimaster

This comment has been minimized.

Show comment
Hide comment
@cfjedimaster

cfjedimaster Apr 17, 2013

Can we at least agree to document it? It still isn't mentioned here: http://api.jquerymobile.com/taphold/

cfjedimaster commented Apr 17, 2013

Can we at least agree to document it? It still isn't mentioned here: http://api.jquerymobile.com/taphold/

@toddparker

This comment has been minimized.

Show comment
Hide comment
@toddparker

toddparker Apr 17, 2013

Contributor

I think documenting it is a great idea.

On Apr 17, 2013, at 10:26 AM, Raymond Camden notifications@github.com wrote:

Can we at least agree to document it? It still isn't mentioned here: http://api.jquerymobile.com/taphold/


Reply to this email directly or view it on GitHub.

Contributor

toddparker commented Apr 17, 2013

I think documenting it is a great idea.

On Apr 17, 2013, at 10:26 AM, Raymond Camden notifications@github.com wrote:

Can we at least agree to document it? It still isn't mentioned here: http://api.jquerymobile.com/taphold/


Reply to this email directly or view it on GitHub.

@arcreative

This comment has been minimized.

Show comment
Hide comment
@arcreative

arcreative Apr 26, 2013

This is really unfortunate behavior--the problem for me is not that it's occurring, per se, but that it propagates to other elements and there's no way to stop it because it's a completely different event trigger. For instance, I'm using a swipeleft event to swipe a view, but when done over another UI element (a contact selection field in this case), the tap registers on the field as well as the swipe on the element below. The only thing I can think to do is provide a virtual interface above it to allow/stop propagation to below elements, which is complicated and unnecessary.

@arschmitz waiting to determine if it's a taphold is no different than the way that touch determines tap vs. click. If the touchstart and touchend events occur in less than the tap threshold, then you're not delaying the tap, nor disabling te taphold functionality. In fact, the tap event isn't even fired until you let go and it triggers both the taphold and tap events, so I don't think the delay wouldn't be a problem.

I propose that swipe, swipeleft, swiperight, and taphold all do not trigger a tap when executed.

arcreative commented Apr 26, 2013

This is really unfortunate behavior--the problem for me is not that it's occurring, per se, but that it propagates to other elements and there's no way to stop it because it's a completely different event trigger. For instance, I'm using a swipeleft event to swipe a view, but when done over another UI element (a contact selection field in this case), the tap registers on the field as well as the swipe on the element below. The only thing I can think to do is provide a virtual interface above it to allow/stop propagation to below elements, which is complicated and unnecessary.

@arschmitz waiting to determine if it's a taphold is no different than the way that touch determines tap vs. click. If the touchstart and touchend events occur in less than the tap threshold, then you're not delaying the tap, nor disabling te taphold functionality. In fact, the tap event isn't even fired until you let go and it triggers both the taphold and tap events, so I don't think the delay wouldn't be a problem.

I propose that swipe, swipeleft, swiperight, and taphold all do not trigger a tap when executed.

@barbalex

This comment has been minimized.

Show comment
Hide comment
@barbalex

barbalex May 2, 2013

I'm extremely surprised that it seems not to be possible to implement different actions on taphold than on tap or click. And that this does not seem to be needed????!!!

How on earch am I going to present a menu when the user holds the tap in a listview for example, without having the tap action happening?
There absolutely needs to be a documented way to do this.
This is basic UI experience.
Somehow I get the feeling that I must be missing out something very basic here.

Please enlighten me and add the explanation where taphold is documented.

barbalex commented May 2, 2013

I'm extremely surprised that it seems not to be possible to implement different actions on taphold than on tap or click. And that this does not seem to be needed????!!!

How on earch am I going to present a menu when the user holds the tap in a listview for example, without having the tap action happening?
There absolutely needs to be a documented way to do this.
This is basic UI experience.
Somehow I get the feeling that I must be missing out something very basic here.

Please enlighten me and add the explanation where taphold is documented.

@barbalex

This comment has been minimized.

Show comment
Hide comment
@barbalex

barbalex May 2, 2013

I tried two ways around the problem:
using vmouseup and -down as explained here:
http://stackoverflow.com/questions/10502383/jquery-calling-click-event-after-taphold-event?lq=1
and changing the jQM code or overriding it as explained here:
http://stackoverflow.com/questions/11759049/tap-event-fired-after-taphold-jquery-mobile-1-1-1

Both ended up flashing the page the list changes to when tapped first an then showing the list again. The end result is nice but the flashing is horrible and unusable.

barbalex commented May 2, 2013

I tried two ways around the problem:
using vmouseup and -down as explained here:
http://stackoverflow.com/questions/10502383/jquery-calling-click-event-after-taphold-event?lq=1
and changing the jQM code or overriding it as explained here:
http://stackoverflow.com/questions/11759049/tap-event-fired-after-taphold-jquery-mobile-1-1-1

Both ended up flashing the page the list changes to when tapped first an then showing the list again. The end result is nice but the flashing is horrible and unusable.

@jtblin

This comment has been minimized.

Show comment
Hide comment
@jtblin

jtblin May 8, 2013

@arschmitz Actually there is a very simple fix, add a flag in the taphold handler and test if the flag is set to true before firing the tap event, reset the flag on each mousedown. This does not involve delaying anything as the flag is set to true only in the timeout handler for taphold (on a standard tap the flag will not have been set and the tap event will be triggered normally). I've submitted a pull request, hope you will review and accept it. Let me know if I've missed anything.

jtblin commented May 8, 2013

@arschmitz Actually there is a very simple fix, add a flag in the taphold handler and test if the flag is set to true before firing the tap event, reset the flag on each mousedown. This does not involve delaying anything as the flag is set to true only in the timeout handler for taphold (on a standard tap the flag will not have been set and the tap event will be triggered normally). I've submitted a pull request, hope you will review and accept it. Let me know if I've missed anything.

@arschmitz

This comment has been minimized.

Show comment
Hide comment
@arschmitz

arschmitz May 8, 2013

Member

@jtblin i thank you for looking at this and submitting a pull request. however this ticket was closed as wont fix not because of the delay but because we do not consider this a bug. as this has been the established behavior since before 1.0. this would be a potentially breaking change for many apps the depend on the behavior. I will bring this issue up at our next meeting and perhaps we can add this as an option.

Member

arschmitz commented May 8, 2013

@jtblin i thank you for looking at this and submitting a pull request. however this ticket was closed as wont fix not because of the delay but because we do not consider this a bug. as this has been the established behavior since before 1.0. this would be a potentially breaking change for many apps the depend on the behavior. I will bring this issue up at our next meeting and perhaps we can add this as an option.

@cfjedimaster

This comment has been minimized.

Show comment
Hide comment
@cfjedimaster

cfjedimaster May 8, 2013

Alexander: Is it your belief that more people desire this behavior then are
surprised by it? That seems wrong to me, but, couldn't Jerome's mod be
added but not be the default?

On Wed, May 8, 2013 at 7:33 AM, Alexander Schmitz
notifications@github.comwrote:

@jtblin https://github.com/jtblin i thank you for looking at this and
submitting a pull request. however this ticket was closed as wont fix not
because of the delay but because we do not consider this a bug. as this has
been the established behavior since before 1.0. this would be a potentially
breaking change for many apps the depend on the behavior. I will bring this
issue up at our next meeting and perhaps we can add this as an option.


Reply to this email directly or view it on GitHubhttps://github.com/jquery/jquery-mobile/issues/3803#issuecomment-17602415
.

Raymond Camden, Adobe Developer Evangelist

Email : raymondcamden@gmail.com
Blog : www.raymondcamden.com
Twitter: cfjedimaster

cfjedimaster commented May 8, 2013

Alexander: Is it your belief that more people desire this behavior then are
surprised by it? That seems wrong to me, but, couldn't Jerome's mod be
added but not be the default?

On Wed, May 8, 2013 at 7:33 AM, Alexander Schmitz
notifications@github.comwrote:

@jtblin https://github.com/jtblin i thank you for looking at this and
submitting a pull request. however this ticket was closed as wont fix not
because of the delay but because we do not consider this a bug. as this has
been the established behavior since before 1.0. this would be a potentially
breaking change for many apps the depend on the behavior. I will bring this
issue up at our next meeting and perhaps we can add this as an option.


Reply to this email directly or view it on GitHubhttps://github.com/jquery/jquery-mobile/issues/3803#issuecomment-17602415
.

Raymond Camden, Adobe Developer Evangelist

Email : raymondcamden@gmail.com
Blog : www.raymondcamden.com
Twitter: cfjedimaster

@arschmitz

This comment has been minimized.

Show comment
Hide comment
@arschmitz

arschmitz May 8, 2013

Member

@cfjedimaster i am not saying whether it is desirable or not just that this would be a breaking change and we generally do not introduce breaking changes. This could be added as not default which is why i said i would discuss at next meeting and perhaps add as an option.

Member

arschmitz commented May 8, 2013

@cfjedimaster i am not saying whether it is desirable or not just that this would be a breaking change and we generally do not introduce breaking changes. This could be added as not default which is why i said i would discuss at next meeting and perhaps add as an option.

@cfjedimaster

This comment has been minimized.

Show comment
Hide comment
@cfjedimaster

cfjedimaster May 8, 2013

Ah - I misread the last part of your comment and didn't think you were
going to promote this as an optional thing. Sorry about that!

On Wed, May 8, 2013 at 8:33 AM, Alexander Schmitz
notifications@github.comwrote:

@cfjedimaster https://github.com/cfjedimaster i am not saying weather
it is desirable or not just that this would be a breaking change and we
generally do not introduce breaking changes. This could be added as not
default which is why i said i would discuss at next meeting and perhaps add
as an option.


Reply to this email directly or view it on GitHubhttps://github.com/jquery/jquery-mobile/issues/3803#issuecomment-17605585
.

Raymond Camden, Adobe Developer Evangelist

Email : raymondcamden@gmail.com
Blog : www.raymondcamden.com
Twitter: cfjedimaster

cfjedimaster commented May 8, 2013

Ah - I misread the last part of your comment and didn't think you were
going to promote this as an optional thing. Sorry about that!

On Wed, May 8, 2013 at 8:33 AM, Alexander Schmitz
notifications@github.comwrote:

@cfjedimaster https://github.com/cfjedimaster i am not saying weather
it is desirable or not just that this would be a breaking change and we
generally do not introduce breaking changes. This could be added as not
default which is why i said i would discuss at next meeting and perhaps add
as an option.


Reply to this email directly or view it on GitHubhttps://github.com/jquery/jquery-mobile/issues/3803#issuecomment-17605585
.

Raymond Camden, Adobe Developer Evangelist

Email : raymondcamden@gmail.com
Blog : www.raymondcamden.com
Twitter: cfjedimaster

arschmitz added a commit that referenced this issue May 8, 2013

Taphold: add option to prevent tap from being fired on taphold Fixes #…
…3803 - Taphold fires tap event as well. Thanks to @jtblin for the concept pr #5980
@arschmitz

This comment has been minimized.

Show comment
Hide comment
@arschmitz

arschmitz May 8, 2013

Member

After some quick discussion this morning we have decided to make this optional it has already been added with commit 71e6dfc and will be in 1.4

Member

arschmitz commented May 8, 2013

After some quick discussion this morning we have decided to make this optional it has already been added with commit 71e6dfc and will be in 1.4

@cfjedimaster

This comment has been minimized.

Show comment
Hide comment
@cfjedimaster

cfjedimaster May 8, 2013

Awesome. As an author of an upcoming JQM book, any ETA on 1.4?

On Wed, May 8, 2013 at 9:33 AM, Alexander Schmitz
notifications@github.comwrote:

After some quick discussion this morning we have decided to make this
optional it has already been added with commit 71e6dfchttps://github.com/jquery/jquery-mobile/commit/71e6dfcbc0bbd9abe7d9657fe165c30bacac7535and will be in 1.4


Reply to this email directly or view it on GitHubhttps://github.com/jquery/jquery-mobile/issues/3803#issuecomment-17609691
.

Raymond Camden, Adobe Developer Evangelist

Email : raymondcamden@gmail.com
Blog : www.raymondcamden.com
Twitter: cfjedimaster

cfjedimaster commented May 8, 2013

Awesome. As an author of an upcoming JQM book, any ETA on 1.4?

On Wed, May 8, 2013 at 9:33 AM, Alexander Schmitz
notifications@github.comwrote:

After some quick discussion this morning we have decided to make this
optional it has already been added with commit 71e6dfchttps://github.com/jquery/jquery-mobile/commit/71e6dfcbc0bbd9abe7d9657fe165c30bacac7535and will be in 1.4


Reply to this email directly or view it on GitHubhttps://github.com/jquery/jquery-mobile/issues/3803#issuecomment-17609691
.

Raymond Camden, Adobe Developer Evangelist

Email : raymondcamden@gmail.com
Blog : www.raymondcamden.com
Twitter: cfjedimaster

@arschmitz

This comment has been minimized.

Show comment
Hide comment
@arschmitz

arschmitz May 8, 2013

Member

@cfjedimaster i assume from your profile your talking about the jQuery mobile cookbook. Im also working on this project. 1.4 is shooting for end of june but no hard date. But dont worry @RedWolves and i are actively trying to make sure things stay in sync between the book and the current version so the book will be up to date at release.

Member

arschmitz commented May 8, 2013

@cfjedimaster i assume from your profile your talking about the jQuery mobile cookbook. Im also working on this project. 1.4 is shooting for end of june but no hard date. But dont worry @RedWolves and i are actively trying to make sure things stay in sync between the book and the current version so the book will be up to date at release.

@cfjedimaster

This comment has been minimized.

Show comment
Hide comment
@cfjedimaster

cfjedimaster May 8, 2013

Nope, it is the JQM book I wrote with Andy Matthews with Pakt. Already out
but working on the update.

On Wednesday, May 8, 2013, Alexander Schmitz wrote:

@cfjedimaster https://github.com/cfjedimaster i assume from your
profile your talking about the jQuery mobile cookbook. Im also working on
this project. 1.4 is shooting for end of june but no hard date. But dont
worry @RedWolves https://github.com/RedWolves and i are actively trying
to make sure things stay in sync between the book and the current version
so the book will be up to date at release.


Reply to this email directly or view it on GitHubhttps://github.com/jquery/jquery-mobile/issues/3803#issuecomment-17610030
.

Raymond Camden, Adobe Developer Evangelist

Email : raymondcamden@gmail.com
Blog : www.raymondcamden.com
Twitter: cfjedimaster

cfjedimaster commented May 8, 2013

Nope, it is the JQM book I wrote with Andy Matthews with Pakt. Already out
but working on the update.

On Wednesday, May 8, 2013, Alexander Schmitz wrote:

@cfjedimaster https://github.com/cfjedimaster i assume from your
profile your talking about the jQuery mobile cookbook. Im also working on
this project. 1.4 is shooting for end of june but no hard date. But dont
worry @RedWolves https://github.com/RedWolves and i are actively trying
to make sure things stay in sync between the book and the current version
so the book will be up to date at release.


Reply to this email directly or view it on GitHubhttps://github.com/jquery/jquery-mobile/issues/3803#issuecomment-17610030
.

Raymond Camden, Adobe Developer Evangelist

Email : raymondcamden@gmail.com
Blog : www.raymondcamden.com
Twitter: cfjedimaster

@arcreative

This comment has been minimized.

Show comment
Hide comment
@arcreative

arcreative May 8, 2013

Thanks for considering this--I was of the opinion that a breaking change is overshadowed by the fact that the behavior seems plain wrong, but I suppose having the option is good enough :-)

arcreative commented May 8, 2013

Thanks for considering this--I was of the opinion that a breaking change is overshadowed by the fact that the behavior seems plain wrong, but I suppose having the option is good enough :-)

@arcreative

This comment has been minimized.

Show comment
Hide comment
@arcreative

arcreative May 8, 2013

By the way, can we have this implemented for swipes as well?

arcreative commented May 8, 2013

By the way, can we have this implemented for swipes as well?

@arschmitz

This comment has been minimized.

Show comment
Hide comment
@arschmitz

arschmitz May 8, 2013

Member

@arcreative swipe works quite different there is no possibility of a swipe with out it being a left or right swipe the purpose of having both is some people may not care which direction so they can just bind to swipe.

Member

arschmitz commented May 8, 2013

@arcreative swipe works quite different there is no possibility of a swipe with out it being a left or right swipe the purpose of having both is some people may not care which direction so they can just bind to swipe.

@realtebo

This comment has been minimized.

Show comment
Hide comment
@realtebo

realtebo May 8, 2013

A big thanks even from me !!! Actually we're modifying the library to avoid this 'not-so-bad-behaviour' .

Thanks, we'll wait for 1.4, and now will go on with self-made hotfixes

realtebo commented May 8, 2013

A big thanks even from me !!! Actually we're modifying the library to avoid this 'not-so-bad-behaviour' .

Thanks, we'll wait for 1.4, and now will go on with self-made hotfixes

@arcreative

This comment has been minimized.

Show comment
Hide comment
@arcreative

arcreative May 8, 2013

@arschmitz But the scenario is essentially the same--I'm swiping in my UI and the final lift of the finger triggers a tap on the element under your finger. This results in a correct swipe, but also clicks on the element as well, which I don't want. I seem to recall that the code works the same way for swipe as it does for taphold, unless I'm mistaken.

arcreative commented May 8, 2013

@arschmitz But the scenario is essentially the same--I'm swiping in my UI and the final lift of the finger triggers a tap on the element under your finger. This results in a correct swipe, but also clicks on the element as well, which I don't want. I seem to recall that the code works the same way for swipe as it does for taphold, unless I'm mistaken.

@arschmitz

This comment has been minimized.

Show comment
Hide comment
@arschmitz

arschmitz May 8, 2013

Member

@arcreative sorry misunderstood your question thought you wanted to prevent swipe on swiperight/swipeleft however the tap and swipe events have nothing to do with each other and should not prevent each other. by this same logic we should prevent click, vclick etc. however the swipe event and its triggering are extensible so you can extend them to work however you wish.

Member

arschmitz commented May 8, 2013

@arcreative sorry misunderstood your question thought you wanted to prevent swipe on swiperight/swipeleft however the tap and swipe events have nothing to do with each other and should not prevent each other. by this same logic we should prevent click, vclick etc. however the swipe event and its triggering are extensible so you can extend them to work however you wish.

@barbalex

This comment has been minimized.

Show comment
Hide comment
@barbalex

barbalex May 8, 2013

Great news, will implement taphold to open menus the minute this option
gets available
Thanks guys
Alex

Am Mittwoch, 8. Mai 2013 schrieb Alexander Schmitz :

@arcreative https://github.com/arcreative sorry misunderstood your
question thought you wanted to prevent swipe on swiperight/swipeleft
however the tap and swipe events have nothing to do with each other and
should not prevent each other. by this same logic we should prevent click,
vclick etc. however the swipe event and its triggering are extensible so
you can extend them to work however you wish.


Reply to this email directly or view it on GitHubhttps://github.com/jquery/jquery-mobile/issues/3803#issuecomment-17617364
.


Alexander Gabriel
Wiesenstrasse 22
8800 Thalwil
079/ 372 51 64
alex@barbalex.ch
www.barbalex.ch

barbalex commented May 8, 2013

Great news, will implement taphold to open menus the minute this option
gets available
Thanks guys
Alex

Am Mittwoch, 8. Mai 2013 schrieb Alexander Schmitz :

@arcreative https://github.com/arcreative sorry misunderstood your
question thought you wanted to prevent swipe on swiperight/swipeleft
however the tap and swipe events have nothing to do with each other and
should not prevent each other. by this same logic we should prevent click,
vclick etc. however the swipe event and its triggering are extensible so
you can extend them to work however you wish.


Reply to this email directly or view it on GitHubhttps://github.com/jquery/jquery-mobile/issues/3803#issuecomment-17617364
.


Alexander Gabriel
Wiesenstrasse 22
8800 Thalwil
079/ 372 51 64
alex@barbalex.ch
www.barbalex.ch

jtblin added a commit to jtblin/jquery-mobile that referenced this issue May 9, 2013

Taphold: add option to prevent tap from being fired on taphold Fixes #…
…3803 - Taphold fires tap event as well. Thanks to @jtblin for the concept pr #5980

jtblin added a commit to jtblin/jquery-mobile that referenced this issue May 9, 2013

Taphold: add option to prevent tap from being fired on taphold Fixes #…
…3803 - Taphold fires tap event as well. Thanks to @jtblin for the concept pr #5980
@eddskt

This comment has been minimized.

Show comment
Hide comment
@eddskt

eddskt Jan 12, 2018

I still have problems, with jquery-mobile's taphold, I solved the problem of the click called after taphold, putting a timeout on the element.
JQM 1.4 with emitTapOnTaphold = false;

Example:
$ (". element") on ("taphold", function () {
        // function her

         setTimeout (function () {
             $ (this) .blur();
         400);
});

eddskt commented Jan 12, 2018

I still have problems, with jquery-mobile's taphold, I solved the problem of the click called after taphold, putting a timeout on the element.
JQM 1.4 with emitTapOnTaphold = false;

Example:
$ (". element") on ("taphold", function () {
        // function her

         setTimeout (function () {
             $ (this) .blur();
         400);
});

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