cancel native events on hammer event trigger? eg touch

[annam]

Hello,

I have the following issue: http://stackoverflow.com/questions/24998194/hammer-js-click-triggered-on-dom-elements-behind-tapped-after-tap-action

I hope to prevent it but cancelling native events to prevent them from bubbling/triggering on other elements after they are used on a hammer instance. for example on touchend (which is used on eg tap) touch (and click) events should not be triggered on other elements.

is there a way to do this? perhaps with a custom listener? shouldn't it be the default behaviour anyway? I'm using hammer v1 but I can update if this issue can be solved in v2 but not in v1..

I can find a number of similar issues being reported on both this repository and on stackoverflow

thanks!

[mgustafsson1]

I can confirm that I have the same issue with v2, at least in the native Android browser (tested on 4.1).
iOS Safari and Chrome work fine.

[annam]

Actually the problem is replicable in ios safari and chrome (try this jsfiddle http://jsfiddle.net/annam/xGJZL/embedded/result/ - tappin on the pink box should not toggle the label below)

[jtangelder]

Over here is an interesting solution for this issue...
It isn't really a bug from Hammer, more like a browser issue regarding touchend/click.
https://developers.google.com/mobile/articles/fast_buttons?csw=1#ghost

Hopefully i find some time next week to take a look at this.

Btw, If i find a robust solution, it will be fixed in v2, or just as a small extra script you can include.

[mgustafsson1]

Hmm that should do the trick.
To give you some more context - I was seeing this problem when I had a popup/overlay and then

1. "Hammer-Tapped" an icon to close the overlay
2. Overlay was closed
3. The click would trigger after 300ms on whatever was "behind" the overlay's close icon, or rather whatever was in the x/y-coordinates where the tap occurred.

[jtangelder]

preventing default on touchend, seems to prevent a click event, i've updated the jsfiddle, and it seems to work, (at least in chrome emulating an ipad)

http://jsfiddle.net/xGJZL/22/

But i guess this doesn't really do the trick, since the Google article i posted exists

[jtangelder]

I've created this small gist. It's based on the code from the Google article.
https://gist.github.com/jtangelder/361052976f044200ea17

Haven't tested it, but i guess it works!

[annam]

Hi Jorik,

thanks for your help. We are looking into the e.gesture.srcEvent.preventDefault() solution. It seems to work on hammer v2, even though the custom e.gesture.preventDefault functions that were integrated in v1 didn't do the trick, and neither did the e.gesture.srcEvent.preventDefault() work on v1 (it seems to target touchmove instead of touchstart).

we'll need to upgrade to hammer v2 to use this solution. hopefully we won't come across many conflicts. i'll keep you updated on whether this solves the issue! Thanks again.

Cheers,
Anna

[annam]

Fyi we've also just tested the clickbuster solution, thanks for putting it together!

It works for preventing labels below to get toggled, and also prevents "click" events binded on items below to be triggered! (both hammer v1 and v2)

However it does not prevent input fields from getting the focus (and popping up the keyboard).

We've also had a conflict with the gsap library (greensock.com) where when the tap event propagates, any draggable components below somehow get semi-initialised. clickbuster doesn't solve this either.

e.gesture.srcEvent.preventDefault() seems to solve all four of the issues :) I guess depending on the use cases of other users who have the same problem one of the two solutions would be suitable.

thanks again for your help!
Anna

[jtangelder]

Cool! I think preventing focus of input elements shouldnt be done with catching any mouse/touch input, but just by adding the disabled property on a input element. Because people still can find other ways to get focus on the element (like pressing the Tab key)

I don't know about the GSAP library, but i guess draggable components make use of the dragstart event, you might can add this to the clickbuster code, around L74.

[annam]

Hi Jorik,

we do want the input to be focusable. The issue is that if you tap on an element to hide itself and show the input in its place, the input gets focused by the "tap to hide" interaction.

[mischkl]

Any word on getting this integrated into Hammer.js itself? We are in the midst of deciding on various frameworks and at the moment ngTouch is the only one that manages to solve the ghost click problem out of the box. It would be mighty reassuring to hear whether this is planned for Hammer in the near future. :)

[runspired]

Closing in favor of #808