No way to stop a link from being followed with some custom event (tap, taphold) #1464

22222 opened this Issue Apr 18, 2011 · 4 comments


None yet

3 participants

22222 commented Apr 18, 2011

When a normal click event is bound to a link, returning false will stop the link from being followed. But this doesn't appear to work with the some of the custom link types.

I've tried vclick, tap, and taphold in Chrome and can't find any way to cancel the default behaviour of the link without also using a click event. I'm using version 1.0a4.1.

See for an example.

@jblas jblas was assigned Apr 18, 2011

Kin - is this still an issue?

jblas commented Sep 2, 2011

@22222 @toddparker

I'm not sure the "tap" event was intended to be an alias for the "click" event. I think the intent was to give the developer some way to trigger an action on touchend (for touch devices) instead of waiting the 300ms or so before the browser got around to synthesizing the related mouseup/click. With that intent in mind, I'm not sure calling preventDefault() on a "tap" event should prevent the default action of a link.

Now "vclick" is a different story. Calling preventDefault() on a "vclick" event should prevent a link for executing its default action. It actually does do what you expect on a touch device, but there is currently a bug in the mouse event handling code for where the isDefaultPrevented(), isPropagationStopped(), and isImmediatePropagationStopped() settings are not being propagated from the virtual event to the original mouse event. I have a fix for this.

In all 3 cases ("vclick", "tap", and "taphold") the stopPropagation() and stopImmediatePropagation() should NOT execute any handlers that follow the one doing the stop, and the events should cease to bubble up the DOM tree.

There seems to be a bug in the implementation of "taphold" where 2 elements in the same parent/child hierarchy that are bound to "taphold" each fire-off their own "taphold" timer. This means that if the child element is the thing being tapped, 2 timers will be fired off, one for the child and one for the parent/ancestor, resulting in 2 different events bubbling up the tree.

jblas commented Sep 2, 2011

I pushed some fixes to the HEAD:



jblas - with these fixes you pushed, I'm going to close this as fixed. Feel free to re-open if that's not the case.

@toddparker toddparker closed this Sep 6, 2011
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment