Draggable+ThrowProps = No Scrolling

[BSaunders]

FIRST QUESTION:  THROWPROPS ISNT WORKING FOR ME.

 

Probably just user error.  Im trying to get draggable setup along with throwProps.

 

I have these files attached:

   <script type="text/javascript" src="...TweenMax.min.js"></script>

   <script type="text/javascript" src=" ... draggable.min.js"></script>

   <script type="text/javascript" src="...ThrowPropsPlugin.min.js"></script>

 

I call Draggable.create($element, {type: "scrollLeft", edgeResistance: 0.5, lockAxis: true, throwProps: true});

 

RESULT:  It creates a draggable frame as expected, but letting go of mouse just sends the div back to its original position.  Maybe Im doing something wrong?  Not sure how to check.

 

Note that if I ditch throwProps:true, the dragging works as expected.

 

EDIT:  Adding correct ref to throwPropsPlugin (see #3 below).

[Diaco]

Hi BSaunders 

 

pls make a reduced Codepen Demo available for you question

 

and check codepen example here and fork that if you still have any problem .

[GreenSock]

I'll echo Diaco's request for a codepen demo, but I wanted to chime in with a couple of quick comments:

• It kinda sounds like you don't have ThrowPropsPlugin loaded properly. I see that you're a Business Green member (yay), so you should have access to that in your bonus zip. 
• There's a typo in your script include (missing a period): ThrowPropsPluginmin.js instead of ThrowPropsPlugin.min.js 

[BSaunders]

That typo exists above, but not in the actual code.  Trouble with codePen is that it's not my live environment ... so it doesn't help me solve the problem (it just gives you a reason to punt).

 

I did find another post that lists the objects required for draggable.  I put a breakpoint in the jscript at the point the draggable object is created, and I can see all of the objects are defined.  I've highlighted the spot that tells me throwprops is loaded...

 

FYI - the version in codepen is 0.9.8 and the version I downloaded is 0.9.9 (another reason codepen isn't super-helpful in solving real life problems).

 

Also - I changed it up to use the non-minified version(s) of your files and I can step into ThrowPropsPlugin.js just fine (Im following down to line 297 on that file ... then I get really lost in your tween.render method ... started to tear up ... had to take a break and drink a little).

 

So if draggable.js 1141 calls ThrowPropsPlugin.js 288 correctly, then I have that module loaded, right?

 

Like I said, draggable works - just not this easing thing.

[Carl]

When offering support its best for us to verify that your code and ours is legit before getting into the specifics of what might be happening in your environment.

 

A CodePen (or jsfiddle or similar) allows us to very quickly verify a number of very important factors. 

Quite often the problem lies in the css and / or html.

When people just post a few code fragments it doesn't give us much to go on (especially when there are typos).

 

Don't worry we can easily check different versions of ThrowProps if the issue appears related to that. 

 

You have 3 people who are eager to help you, its just very difficult with the information you have provided.

[BSaunders]

That's so cool - you guys are the greatest!

 

Since Im POSITIVE you guys have lost money just by looking at my lengthy freakin email, I'll go get them to upgrade to business lifetime or something on Monday.  

 

Maybe you should have a support team tip jar on the site.

 

OK - here's what I did, I deployed a new build to our staging server and added a test account for you to see the problem.  It's not a public site, so ... you know ...

 

1.  Login to stage.bigtime.net with 

 

user name: gsbigtime@mailinator.com

password: test123

 

2.  Once you're there, browse to Reports...Report Center 

    (https://stage.bigtime.net/Bigtime/Report2#/list)

 

3.  Change your browser size to 480px or so wide (responsive).

 

4.  See that top list of "tiles"?  Drag em lefty/righty.

 

The code is mostly combined, but not minified, and I changed the build so that it just uses the raw/uncompressed versions of your 3 js files (in case you want to step/debug): 

 

..Content/js/lib-jquery/2014/draggable/TweenMax.js

..Content/js/lib-jquery/2014/draggable/draggable.js

..Content/js/lib-jquery/2014/draggable/ThrowPropsPlugin.js

 

The actual DRAGGABLE object is created at this location (sorry - those files are all combined, but I did turn off minification so you can see wtf):

 

..content/js/ajsreporting_combined_20150509.js: 4301 

 

It's inside of an angularJs directive (not that it matters, but that's whats up with the function it's in).

 

Thanks in advance for looking gents.  Seems to be ok in the attached fiddle (https://jsfiddle.net/sctsgtum/9/) so must be environmental.

[GreenSock]

Thanks for taking the time to not only provide access to the environment you're working in, but [more importantly] creating a reduced test case in jsfiddle. It sure looks like you've got something else that forces the scrollLeft back to zero when the mouse is released. I'm pretty sure it's not Draggable, but let me know if you see any evidence to the contrary. As your jsfiddle showed, Draggable works great with that [extracted] setup, so something else in that environment appears to be messing with things. Perhaps there's an Angular-specific chunk of code that's doing it? I'm not familiar with Angular, so I'm not entirely sure what it does under the hood. 

 

Maybe it'd help to keep building up your jsfiddle to be more and more like your production environment and see when it breaks so that you can isolate the incremental step.

 

Another random thought: is your code (or Angular) rebuilding that list or something when the mouse releases? I guess that'd explain the behavior. 

[OSUblake]

One problem I see is that the draggable and the wrapper are the same width. The draggable should be wider than the wrapper, which it is in your fiddle. This thread kind of touches on that.

http://greensock.com/forums/topic/11580-draggable-children-click/?hl=autoscroll#entry47201

 

Have you tried running it without extending the props, and not setting the overflow immediately afterwards?

 

Also, I'm getting _ticker.time and vp.t2 NaN values in the console from the ThrowPropsPlugin. Don't know what those mean, but I see a lot NaN ticks being thrown around. When creating directives in Angular, a digest cycle must run a couple times before you can initialize some things. Try running $timeout 2 times before trying to create it.

$timeout(function() {
  $timeout(function() {
    // Create it here
  });
});

// Since you're using underscore, you can also do this...
_.defer(function() {
  _.defer(function() {
    // Create it here
  });
});

[BSaunders]

Also, I'm getting _ticker.time and vp.t2 NaN values in the console from the ThrowPropsPlugin. Don't know what those mean, but I see a lot NaN ticks being thrown around. 

 

I added a couple of console.write commands to the ThrowPropsPlugin to see whats up with those properties.  Seems like the fact that _ticker.time and vp.t2 are NaN at that point in ThrowPropsPlugin is what's causing the fail.

 

The same writes are available on the fiddle (and those properties aren't NaN).  You can break on the create to see that angular is finished manipulating the dom before the draggable object is created, but I'll take a look at the timeouts... maybe wait 10s so that I know angular isn't working with it.

[OSUblake]

Setting some arbitrary delay may not do anything if the digest cycle hasn't finished. Even though _.defer is not tied to Angular, it can still work because it is delaying execution based on cycles. However, it is probably better to use $timeout because it also updates the $scope, which may have changed if you have some other directives that were loaded after your draggable.

 

When I first started learning Angular, I ran into issues like this all the time, with some pretty unexpected results. For example, GSAP was able to manipulate the DOM one cycle before jQuery which would really mess stuff up, especially with draggable's hit detection. Now I always unwrap my elements before feeding them into GSAP.

 

Here's some useful information about animations and Angular cycles.

https://github.com/angular/angular.js/issues/5130

http://stackoverflow.com/a/17958847/2760155

[BSaunders]

Turns out its not angularJs (although angular is big enough that I could see that being a red herring).  Turns out it's the presence of a now function on the Date prototype (in my case, added by the dateJs library).

 

TweenMax.js (at 5701) has the following declarations (emphasis mine):

var _reqAnimFrame = window.requestAnimationFrame,
   _cancelAnimFrame = window.cancelAnimationFrame,
   _getTime = Date.now || function() {return new Date().getTime();},
   _lastUpdate = _getTime();

Because dateJs adds a now method, _getTime is set to an existing function (one that returns today's date/time) instead of the IE9+ function that returns the whole milisecond data gs is expecting.  Not sure why that line looks for now first (instead of just setting _getTime to a function), but the following change seems to work in all the browsers I have access to on a sunday afternoon.

 

_getTime = function() {return new Date().getTime();},

 

I can adjust to fix, but thought you'd want to take a look and decide if it's worth adjusting in the library(thought i'd pass it along just in case).  Also - ThrowProps+dateJs = fail without that little adjust (in case anyone else is curious).

 

[OSUblake]

Glad you figured it out, but why are you using Date.js? Hasn't that been replaced by more modern libraries like Moment.js, or do you have some weird legacy thing going on?

[BSaunders]

Glad you figured it out, but why are you using Date.js? Hasn't that been replaced by more modern libraries like Moment.js, or do you have some weird legacy thing going on?

 

If I didn't know better I'd say that was just a tiny bit snotty (wink added post original post in order to soften the following) ...  Of course we have legacy stuff going on, man.  There isn't a real project in the world that doesnt have "legacy stuff."  But kudos for being online on a sunday.

[OSUblake]

My bad. I didn't mean for it to come off sounding like that.

 

I never heard of Date.js, so I did a search and saw some issues about Date.now(), including one that said that it no longer adds it own function anymore. Then I saw that the library hasn't been updated in over 7 years, which kind of shocked me, because that's like centuries in JavaScript years.

 

Again, sorry if I came off sounding like that. I was just curious if it was still needed since it has known issues and hasn't been active for awhile.

 

http://stackoverflow.com/a/7350077/2760155

[BSaunders]

Not at all, man.  You already spent a TON of time on my silly little problem -- so I'm 100% grateful ... just had to give you a (little) hard time.  Now, for godsake, go do something FUN on a sunday.

[GreenSock]

Thanks for letting us know about the problem/solution. Glad it wasn't an issue with GreenSock stuff For the record, our code attempts to prioritize using Date.now() instead of new Date().getTime() for performance and memory reasons. Since it's considered poor practice to modify native functions like that other library did, it's tough to justify tweaking our own code to work around that, especially since it sets a dangerous precedent (what if someone messes with requestAnimationFrame or window or document?). I'm kinda shocked they altered that Date.now() behavior, but I'm very glad that you discovered it and let everybody know here. Good work.

 

Cheers!