Jump to content
Search Community

Strange issues with Draggable

tsneddon test
Moderator Tag

Recommended Posts

I have a Draggable demo that displays some odd behavior, especially in Android webview (and Chrome).

Here's a list of what I am seeing.

 

  1. Swipe arrow to the right and watch what happens. Do the same in Chrome on Android. If you hold your finger for too long, the click event will fire and detach your finger from the draggable element. I've tried everything I can think of to stop this from happening with no luck.
     
  2. In Chrome for Android, if you are swiping down as you begin your touch, it will almost immediately detach from the .circle element. This behavior does not happen on iOS or with Windows using a touch screen.
     
  3. The draggable circle (.circle) is bounded by the containing element (.drag-channel). It appears that the width of the bounding region is correct, but it is misaligned as it starts at the outside edge of the lefthand border of .drag-channel. Because of that, it stops short of reaching the righthand edge of the .drag-channel.
     
  4. In iOS, if you tap the circle and release really fast (it's hard to do), the background color seems to stick in some kind of intermediate state. I'm not sure if this is an issue with the onPress and/or onRelase events, or an internal issue with css in webkit.

 

If someone with more experience with Draggable could take a look at this for me I would appreciate it greatly.

 

Thanks,

    Tom

 

See the Pen qQmzxK by t-sneddon (@t-sneddon) on CodePen

  • Thanks 1
Link to comment
Share on other sites

I haven't had time to look at Android stuff, but...

  • As for (3), that's caused by the fact that you've got different box-sizing. I'll add some code to the next Draggable release to sense that condition, but in the mean time you can just do some calculations and set the bounds like this: 

    See the Pen 00de1f814c4812113e832686fe0b8ada?editors=0010 by GreenSock (@GreenSock) on CodePen

  • As for (4), yeah, that'd have nothing to do with GSAP. You might want to try doing the color change(s) with GSAP instead of CSS, actually. 

The long-touch sounds like maybe you're triggering a context menu or something. Frankly, it's an absolute nightmare trying to normalize behavior across browsers because they all have odd quirks, inconsistencies, bugs, etc. 

 

I didn't quite understand what you meant in (2) - "almost immediately detach from the .circle element". Are you saying the Draggable disconnects...like it suddenly becomes non-draggable? 

 

Would you mind trying the beta for the next release? https://s3-us-west-2.amazonaws.com/s.cdpn.io/16327/Draggable3.min.js

  • Like 2
Link to comment
Share on other sites

Here's a small addition that illustrates the positioning issue. I'm not sure if the issue is with the Draggable plugin, or the browser itself, but somehow the two don't agree on something.

 

I've added both an X and a Y coordinate to return to onDragEnd, even though the circle is only draggable in the X direction. Note that the position of the draggable circle is correct at the begging when the page first loads. After onDragEnd and the circle tweens back to the home position, it is offset in the Y direction the same distance that the drag bounding is off in the X direction.

 

See the Pen JjYmjrw by t-sneddon (@t-sneddon) on CodePen

 

 

Link to comment
Share on other sites

Thank you very much for your reply Jack. I guess our posts crossed in the mail, so to speak.

 

Cross browser issues can be a nightmare. What I'm dealing with is Apache Cordova apps that run in both Android and iOS, so I really only need to deal with Android Webview and Webkit for iOS. Putting in conditional workarounds based on platform is something I try to minimize, but I realize that it is sometimes necessary.

 

Thanks for the suggestions. I'll add them to my bag of tricks. I did realize though that the issue mainly stems from the different box model, but it is nice to be able to create a draggable element, and the do whatever is required to render it visually via the css. I try to keep the functional elements of animations in JavaScript and visual style in css as much as possible.

 

Item 2 in my original post does refer to the draggable element becoming not draggable. If the user's touch is imprecise, and instead of just poking the circle and dragging right, the finger comes to rest with even a slight downward (or upward) swipe, the draggable circle becomes not draggable and the user has to try again. This is only on Android (Webview or Chrome), which is a big deal for me since one half of what I'm creating is Android apps. I believe that there is some underlying issue involved with this behavior, because I have had "detachment" issues in the past with draggable UI elements. In fact, for an app I am currently working on I had to revert from v3.2.6 back to v3.0.2. Something must have changed that caused two of my draggable UI elements to not work. They would detach <edit>in a fraction of a second</edit> if the drag was more than a couple tenths of an inch, when they had functioned flawlessly before updating gsap.

 

Thanks,

   Tom

Edited by tsneddon
Retested my app and updated the description of the error. It is a drag distance issue, not a drag time issue. I'm going to double check my code on Monday to make sure that is isn't something stupid that I've done.
Link to comment
Share on other sites

Beta version of Draggable fixes bounding issue. Thank you!

Beta version of Draggable fixes long touch before dragging. Thank you!

 

Still has issue of detaching if the user slightly swipes down as finger comes in contact with circle. This is easy to see on Android, but on iOS you must precisely swipe vertically as you begin the touch event. It's kind of hard to achive, but because it can be done I guess it removes the browser-specific angle to this issue.

 

See the Pen QWjZwQZ by t-sneddon (@t-sneddon) on CodePen

Edited by tsneddon
Long touch issue added. Retested "swipe down" touch on iOS and Android. Updated description of issue.
Link to comment
Share on other sites

Aha! I think I found the issue. Some browsers support multiple types of events (touch, pointer, mouse) and they don't allow you to just preventDefault() on one (pointerdown/pointermove in this case). It would dispatch a pointerdown event, for example, preventDefault() was called, and then it'd ALSO dispatch a touchstart event and if preventDefault() wasn't called on that one as well, it'd continue with the default action (like scrolling). I altered the code in the latest version to work around that. Please give it a shot and let me know if that works better for you. 

 

Here's a fork that uses the beta and seems to work well for me:

See the Pen f3ad3e2234206aaf6f03f4033de08bb6?editors=0010 by GreenSock (@GreenSock) on CodePen

  • Like 2
Link to comment
Share on other sites

Sorry for the long delay. I've verified that every aspect of this particular issue is solved with the Beta release. Thank you for taking the time and making the effort to help solve this. That's why gsap continues to be the best!

 

I have one other problem that I've been fighting on and off for quite a while, but that will be the subject of another post, since it does not involve any of the original 4 issues of this post.

 

  • Thanks 1
Link to comment
Share on other sites

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...