Jump to content
Search Community

Draggable + multitouch bug

RandomStudio test
Moderator Tag

Warning: Please note

This thread was started before GSAP 3 was released. Some information, especially the syntax, may be out of date for GSAP 3. Please see the GSAP 3 migration guide and release notes for more information about how to update the code to GSAP 3's syntax. 

Recommended Posts

We're encountering an issue using Draggable on a multitouch table (WIndows 8 + Chrome), but it also seems to happen on Android Lollipop, so it's probably a general issue.

 

When dragging an item and you use another finger to tap shortly on the same item, it will be suspended in place, not firing the proper events for ending a drag (onDragEnd, onRelease). Snapping and throwprops will also not work.

 

The issue is easy to reproduce using the sample on https://greensock.com/draggable.

Enable the checkbox for "snap end position to grid". Start dragging one of the squares and then shortly tap on it with another finger. When you release, the square will not snap to a position on the grid.

 

Has anyone encountered this and found a way to fix it? Should I file an issue somewhere?

Link to comment
Share on other sites

Hi Carl,

 

Thanks for the quick response.

 

I realize it's a quite specific interaction, but in our case, with multiple people interacting with the touch-table, there's quite a risk of this happening.

 

Since we're working towards a deadline this week, we really need to get this sorted. We're using Draggable and ThrowProps throughout the application and removing them at this point is not really an option.

 

I've also been doing some debugging and apparently the problem exists because all the touch-listeners are removed on release of the second finger:

 

https://drive.google.com/a/random.nu/file/d/0B8ETgKSVRXvMQnZqRzZCS2ltNU0/view

 

The onRelease event does not trigger onDragEnd (which is fine, because finger one is still dragging), but movement is not registered anymore because all the touch-event listeners are removed afterwards.

 

 

I'll continue to look into it and will keep you posted, but don't really like working with modified libraries. Also there's other parts of this product that need my attention. Do you think it'd be possible for you to implement a solution somewhere this week?

 

Cheers, Thijs

Link to comment
Share on other sites

Sorry to hear about the trouble. Unfortunately, this happens to be the ONE week in the last year (or maybe more) that we have virtually zero bandwidth to really dig into this because I'm traveling and Carl is tied up teaching a class. I'll definitely look at it as soon as I can, but I can't promise that'll be earlier than next week. If you are able to make any progress on implementing a solution, please do send it my way and [assuming it's solid], I'll add it to the official release. I totally know what you mean about not wanting to work with modified flavors of libraries because the next time they release an update, you have to either skip it (and miss any bug fixes or feature enhancements) or monkey-patch your version which is no fun. So rest assured that if your fix doesn't introduce other problems, it's very likely we'll just add it to the official release and you won't have to worry about it. 

 

Again, apologies for not having a super-fast answer.

Link to comment
Share on other sites

Hi @Jonathan,

 

My local version of Chrome is 41.0.2236.0 dev-m (64-bit), running Windows 8.1. Though it's all the same on any other platform and browser I've tested.

 

No worries @GreenSock, I imagine you guys are busy too and it's just a bummer we noticed this so close to our release.

 

I should have some time on my hands later this week and will keep you posted on any progress towards solving the issue.

Link to comment
Share on other sites

  • 4 months later...

The only device I can seem to reproduce this issue on is my somewhat old Android tablet (Amazon Kindle Fire) and it's a particularly gnarly issue because the browser is misreporting things such that I can't figure out any workarounds. Here's a summary of the problems:

  1. The browser doesn't honor touch-action CSS which can disable the native gesture handling, thus when you add another finger to the same element it assumes you're trying to zoom.
  2. The browser fires a touchcancel event at this point. We listen for that in Draggable so that we can appropriately stop the dragging and remove listeners.  If we don't do that, you'll see some odd behavior if, for example, you drag your finger off the screen (that's why we can't just listen for a touchend).
  3. Most significantly, the browser misreports the "touches" and "targetTouches" on the event as 0 even though you still have 1 finger down. That's clearly a browser bug and it makes it virtually impossible for us to properly discern this scenario (a touchcancel that can be ignored). 

If anyone else has ideas, I'm all ears. But from what I can see right now, this behavior is caused by a set of browser bugs that can't really be worked around (at least not that I can figure out at this point). I wish I had better news. :(

Link to comment
Share on other sites

Thanks Jack.

 

I don't have the device on me now so I can check exact versions but for me it was happening on a Nexus 7 running Android Lollipop, current Chrome version off Google Play store as of 8/05/15 and also inside a Crosswalk project (crosswalk-project.org) running the Canary release version 14.43.341.0.

 

I am also using Hammer.js 2.0.4 in the project and that's the only other thing I can think of that may be messing with things.

 

EDIT:  

Device: Nexus 7 running Android 5.1.0

Chrome version: 42.0.2311.111

Edited by pm33
Link to comment
Share on other sites

Just tested on iPad Air running latest iOS and Safari and was easily able to reproduce the same bug.

 

UPDATE 1:

I have not been able to reproduce the bug on the Draggable example on (http://greensock.com/draggable) on the same devices.

 

I can get it to drop the drag element without triggering any events but it doesn't break all draggable elements (as in you can just press and drag it again).

 

 

UPDATE 2:

I am using e.stopImmediatePropagation() in my onPress and onDragEnd functions. When I remove this it functions exactly the same as the Draggable example on (http://greensock.com/draggable) as in it only drops the draggable element without triggering any events and can just be selected and dragged again. Both e.stopPropagation() and e.stopImmediatePropagation()  produce the same behavior.

 

Any ideas on how to trigger some event in this situation and also stop the propagation (The page has swipe handlers from Hammerjs that I don't want triggered while dragging).

 

 

UPDATE 3:

Using monitorEvents(document) in Chrome DevTools there doesn't seem to be anything unusual and all the correct events are being reported.

 

Like you said earlier it does seem to occur when pinch zooming the element. When using stopPropagation it is possible to get draggables working again by pinch zooming a draggable element (it does not have to be the same element that caused the issue nor is this consistent by any means. Hope this make sense).

Edited by pm33
Link to comment
Share on other sites

  • 1 month later...

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...