Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Already on GitHub? Sign in to your account

Fixes cascading touch handling, and a mousedown issue #16

wants to merge 3 commits into


None yet
3 participants

fracmak commented Nov 16, 2011

There are two commits, the first one fixes an issue where an internal widget variable isn't being reset because the mousedown event on the document isn't being triggered correctly with some touch events. The second commit prevents cascading touch events from getting accidentally processed (this fixes an issue I was having with a draggable inside a draggable)

Jay Merrifield added some commits Nov 16, 2011

Jay Merrifield fix an error where the mouse widget's mouseHandled never got reset be…
…cause of a missing mousedown event on the root
Jay Merrifield fix an error where cascading touch handlers aren't handled correctly,…
… this patch first checks if the event has already been handled before triggering the code
Jay Merrifield updated minified version 024b999

great fix.. Just what I needed. This just changed touch punch from a "no go" to a "go on" ;)...

fracmak commented Nov 18, 2011

lol. You're script is brilliant in it's simplicity and power. I have one other change that I'm debating whether it's worth submitting as a patch. It falls into the category of "I need it for my project, but it might not be something everyone else wants". The basic change is that I don't allow a mouse down event to proceed if more than 1 finger is down. This kind of falls in line of we're only simulating single mouse clicks, not multi-finger drags. My situation is that I have a section of my webapp that supports pinch zooming, but there are often jquery draggable widgets on top of it, so you can very easily accidentally "catch" a jquery widget while pinch zooming. Another option would be to allow multi-finger drags, but only if both fingers are on the target element. But that doesn't feel right either. Thoughts?

furf commented on 622ef13 Nov 18, 2011

This commit is a dupe of hconceicao/jquery-ui-touch-punch@d54be92

I will implement and test.

furf commented on 578ed6f Nov 18, 2011

Could you please provide an example where this bug was occurring? Thanks.


fracmak replied Nov 18, 2011


on an ipad, drag Drag1, then drag Drag2. You'll see both react to the drag motion. My patch fixes that error

furf replied Nov 18, 2011

works in the UI 1.8.12 tested on jsfiddle, but not the 1.8.4 i was testing against locally. that caused some confusion :)

your fix works in UI >= 1.8.6. I will have to look at the changes to see if a different or additional fix is necessary. thanks!


fracmak replied Nov 18, 2011

I know why it didn't work in 1.8.4, cause I'm the one that added the patch/workaround to jquery-ui to fix the behavior and I believe it landed in 1.8.6. :-)

furf replied Nov 18, 2011

cool. i added event.preventDefault after _mouseDown.call to make up for the one that was added.


fracmak replied Nov 18, 2011

furf replied Nov 18, 2011

I'm calling right it after jQuery UI >= 1.8.6 calls it in _mouseDown. So I'm not introducing any bugs that jQuery UI didn't introduce themselves ;) Will keep an eye out for unexpected consequences -- probably regarding text selection.

@furf furf added a commit that referenced this pull request Nov 18, 2011

@furf furf fix cascading issue (#16), trigger document mousedown on touchstart (#7
…, #16), added mouseover/mouseout support (#7), refactored event type translation (#7)

@furf furf closed this Nov 18, 2011


furf commented Nov 19, 2011

event.stopPropagation seems to handle the cascading issue without needing preventDefault.

fracmak commented Nov 19, 2011

The problem with that is if there's a root handler like the one the
mouse handler uses on the document, it'll miss the event entirely and
you could get weird behavior bugs. The policy of jquery ui is not to
prevent event propagation.


On Nov 18, 2011, at 7:44 PM, Dave Furfero

event.stopPropagation seems to handle the cascading issue without needing preventDefault.

Reply to this email directly or view it on GitHub:
#16 (comment)

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