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

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

Closed
22222 opened this Issue Apr 18, 2011 · 4 comments

Comments

Projects
None yet
3 participants
@22222

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 http://jsfiddle.net/YL8hj/ for an example.

@ghost ghost assigned jblas Apr 18, 2011

@toddparker

This comment has been minimized.

Show comment
Hide comment
@toddparker

toddparker Aug 8, 2011

Contributor

Kin - is this still an issue?

Contributor

toddparker commented Aug 8, 2011

Kin - is this still an issue?

@jblas

This comment has been minimized.

Show comment
Hide comment
@jblas

jblas Sep 2, 2011

Contributor

@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 jquery.mobile.vmouse.js 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.

Contributor

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 jquery.mobile.vmouse.js 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

This comment has been minimized.

Show comment
Hide comment
@jblas

jblas Sep 2, 2011

Contributor

I pushed some fixes to the HEAD:

7cce0c5

Contributor

jblas commented Sep 2, 2011

I pushed some fixes to the HEAD:

7cce0c5

@toddparker

This comment has been minimized.

Show comment
Hide comment
@toddparker

toddparker Sep 6, 2011

Contributor

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.

Contributor

toddparker commented Sep 6, 2011

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