Even domEvents = true, stopPropogation is not working

[lqzerogg]

I have two elements. One is a parent with tap handler, the other is a child with tap handler. Tapping child should not trigger parent's tap handler. But in fact, it trigger!
I search for a while, but cannot find any solution.
Setting domtEvents: true cannot solve this problem.
Is a a bug? Or I need to set up something else?
Here is my code: http://codepen.io/lqzerogg/pen/wgKJwj

[herom]

This is likely to be related to my issue over at the ember-gestures project html-next/ember-gestures#73

... unfortunately I didn't get an answer over there but maybe we can come up with some solution here? 😃

[lqzerogg]

In fact I use event.target and it's class name to avoid this problem. But I just think it's not a good solution.

[herom]

Yeah, I also thought of "flagging" the already handled event and ignoring further events which are fired within the next 5ms or something like this....

but, all in all I think this is a qualified bug as it simply should not fire twice...

I know that everyone is short on schedule for their open-source projects, but would you mind to take a look at this @arschmitz @runspired ? thanks a ton 👍

[jarrodRiv]

I think this particular issue is because the tap event is fired on the "up" event (pointerup / mouseup / touchend), and those are listened to by hammer at the window, not the dom element itself. So, stopping propagation when the event is already at the window does not prevent the other recognizer from receiving it.

Listening for move / up events on the window is common practice, and allows gestures to still be detected as they leave the original target element.

Two potential workarounds I can think of:

• stop propagation of all events on the nested target (http://codepen.io/anon/pen/vgLbzQ). This may be what you want anyway, and it works because the down events are listened to on the target itself, not the window
• create the child recognizer first (gives it priority) and use stopImmediatePropagation to prevent the later recognizer from receiving the input. (http://codepen.io/anon/pen/apdMmj) This still felt buggy (not sure why)

[lqzerogg]

The first one sounds good!
Still, I hope hammer have a more simple option. Because I think a lot people would run into this trouble and waste lots of time searching for the answer.

[zeorin]

I've also run into this issue…

For now I've worked around it by stopping mousedown and touchstart events on the child elements, but this is really suboptimal.

In my situation, I've got a child element type that is sometimes scrollable. If it's scrollable, then swipeup and swipedown need to be stopped from propagating.

There're swipeup and swipedown handlers further up the DOM tree.

There're also swipeleft and swiperight handlers further up the DOM tree, too (in a different place to the swipeup and swipedown handlers), but these should always fire whether or not the child element is scrollable.

Luckily there's some space around the child elements that'll mean that the UX is not broken, just tricky (if the users swipe left or right in the padding surrounding a scrollable child element, the swipeleft or swiperight handler will still fire). There're also buttons.

I've also implemented this scenario for the native wheel event, and it works great, feels very intuitive. It's a shame I can't get it to work with swipes (and presumably also pans, but I haven't gotten there yet).