Draggable blocks native scroll event

[OSUblake]

Ummm... I guess it was some kind of phantom glitch, because it's working properly now. And this problem wasn't limited to CodePen or any particular browser.

 

What was happening when you pressed it, is that it would fire onPress -> onDragStart -> onDrag. Likewise, when you released it, it would fire onRelease -> onDragEnd.

 

This problem started when I went to test out the Draggable update with a project that I was working on, and I noticed that all my callbacks were firing during a mouse press . I cleared my cache multiple times, and the problem still persisted, so I recreated the problem in CodePen and made that post. I'm pretty sure Diaco saw what was going on because his suggestion of rounding the values in a snap function fixed the problem at that time. As to why it's working now, I'm clueless. 

[GreenSock]

Not sure what happened, but I did run into a caching issue and I had to add a ?r=993 (random number) to the end of the URL to make sure I was getting the latest TweenMax and Draggable. Maybe you had a similar thing going on. I dunno, but please let me know if you run into any issues. If anyone else can reproduce the issue, I'd love to hear about it. I double-checked the latest code and I didn't see any issues that'd cause that behavior, although I every well may have missed something. It seems to be workin' like a champ now. 

[OSUblake]

If Diaco can confirm that he saw my problem, then I'm guessing it might have been some sort of caching issue we were both experiencing. If he didn't see my problem, and just guessed that snapping the values would fix it, then I'm thinking that my touch monitors were the culprits. Maybe some dirt or a smudge was interfering with the events. I do have an unresolved issue with my touch monitors, although I wasn't using both of them when I encountered this problem.

 

[GreenSock]

Alright, thanks OSUblake. So is it safe to say that things are performing great with the latest beta? If there are any problems at all, please let me know ASAP, as I'd like to get it launched. 

[OSUblake]

Everything seems to be resolved on my end, so I'd say it's a go.

[Diaco]

Yep , everything works great as always now , seems that was just a caching issue 

[GreenSock]

FYI, 1.16.1 has launched. We're still waiting for the CDN to update though. Thanks for all the input, guys!

[OSUblake]

Just noticed this in the update. What's the diagonalThreshold for in getDirection, and how does it work?

[GreenSock]

OSUblake, you sneaky devil you. Inspecting the source and sniffing out those undocumented parameters, huh?

 

I chose not to document that parameter for now because I wanted to wait to see if anyone brings up use cases where it's beneficial. Sometimes I'll do that, and then it's nice because it's there if we need it, but it gives us some flexibility in terms of our commitment level to a particular feature/parameter. 

 

diagonalThreshold is a number that basically controls how sensitive it is to diagonal movement. If you set it to 1, it will only report "up", "right", "down", or "left" (no diagonals). However, if you set it to 2 (the default), there's a certain range between which it'll return the diagonal values like "up-left", "up-right", "down-left" or "down-right". The higher the number, the wider that range gets (the more likely you'll get those combo-values). It should never be set below 1. 

 

Why a simple number like that? Mostly because I'm using an optimized algorithm internally that leverages ratios rather than doing more CPU-intensive angle-based Math.atan2() or Math.cos() or Math.sin(). Those all boil down to ratios anyway. 

 

So the moral of the story is: diagonalThreshold can be set to 1 if you want to prevent mixed-values, or you can increase the number to make it more and more likely to return the diagonal combo-values. 

 

Make sense or did I botch the explanation? 

[jermbo]

This is why I LOVE GSAP!

I am having the same exact problem being described here in my current project. 

 

At first I was doing what the other forum replies suggested, by disabling the ones not in play. That works, but kills phone performance. 

I have been pulling my hair out trying to figure out a performant way of doing this. 

 

Love the new updates as well!!

[usheeen]

Kind of amazing that Jack and Carl were able to add this functionality as a drop in, non breaking update.

[GreenSock]

It would only be fair to tip our hat to usheeen, Diaco, and OSUblake - all of whom were instrumental in providing the feedback and suggestions that ultimately got it working in Draggable. Thanks guys.