Jump to content
Search Community

GSAP and Mootools 1.4.5 compatbility issue

RolandSoos 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

Hi!

Sadly, Joomla users still use Mootools 1.4.5 and there is a compatibility issue with GSAP. Mootools add functions to the prototype of the array, for example:

Array.prototype.test = function(){

}


var myArray = [1];

for(var k in myArray){
    console.log(k) 
}
/*
Output:
 - 0
 - test
 
To get the proper output:
*/

for(var k in myArray){
  if(myArray.hasOwnProperty(k)){
    console.log(k) 
  }
}
/*
Output: 
 - 0
*/

 

 

So I was not able to reproduce this issue in Codepen as there should be something in my system which triggers the error, but here are the clues.

The vars variable hold the array which looped through with for ... in. Probably vars should be object and you can safely use for ... in.

 

Call stackhttps://i.imgur.com/UwMyhlG.png

 

._kill https://i.imgur.com/p6zEyfg.png

._applyOverwritehttps://i.imgur.com/CXRmShX.png

.initPropshttps://i.imgur.com/OZakdII.png

._inithttps://i.imgur.com/hnTSmnt.png

 

 

vars holds the value of the this._propLookup which inited as array in .invalidate() and in TweenLite constructor.

 

 

  • Like 1
Link to comment
Share on other sites

This is so beyond me I don't even think I understand what's going on...

 

But, I do know we will need some way to see the issue. I understand it's something to do with Joomla, not GSAP itself but, do you think you can get a minimal installation somewhere that highlights the issue?

 

Also, what is the issue? I'm not sure I follow what went wrong.

  • Like 1
Link to comment
Share on other sites

Thanks @Dipscom, well, Joomla is not really related. The only thing which is related the Mootools changes the prototype of the Array. 

 

So placing the following before GSAP should be able to trigger this behavior.

 

Array.prototype.test = function(){

}

 

Well, finally I was able to reproduce it in Codepen :)

 

See the Pen zQPBwQ?editors=0010 by mm00 (@mm00) on CodePen

 

When the invalidate() call removed, the example works as expected.

I need to call the invalidate() as in my example that timeline reinserted into new timelines all the time. 

 

@GreenSock: I changed the following in TweenLite:

this._propLookup = [];

To:

this._propLookup = {};

and

this._propLookup = (this._targets) ? {} : [];

To:

this._propLookup = {};

 

Everything seems to works normally. Also I tracked and this._propLookup only used as array when you loop through this._targets array, in those loops you use the this._targets.length, so the this._propLookup can be accessed in the object just fine.

 

  • Like 1
  • Thanks 1
Link to comment
Share on other sites

Ah, very interesting. Good catch. It looks like those two values are inverted. I can update the next release which you can preview (uncompressed) here:

https://s3-us-west-2.amazonaws.com/s.cdpn.io/16327/TweenMax-latest-beta.js

 

In the mean time, you could edit the TweenLite.prototype like this: 

TweenLite.prototype.invalidate = function() {
  if (this._notifyPluginsOfEnabled) {
    TweenLite._onPluginEvent("_onDisable", this);
  }
  var t = this._time;
  this._firstPT = this._overwrittenProps = this._startAt = this._onUpdate = null;
  this._notifyPluginsOfEnabled = this._active = this._lazy = false;
  this._propLookup = (this._targets) ? [] : {};
  com.greensock.core.Animation.prototype.invalidate.call(this);
  if (this.vars.immediateRender) {
    this._time = -0.00000001;
    this.render(t, false, this.vars.lazy !== false);
  }
  return this;
}

 

Just drop this in once after you load GSAP and it should resolve things. 

 

Thanks again for the reduced test case. Very helpful!

  • Like 3
Link to comment
Share on other sites

Thanks @GreenSock!

And there is no chance that this._propLookup is array and GSAP reaches ._kill with that array right?

 

I assume that this._propLookup was originally an array, which holds a lookup table for every animated elements in that tween. So if the same tween contains multiple path, the _proplookup looks like: [0: {... lookup table for element 1...}, 1: {... lookup table for element 2...}, ...], but there is an optimization when the tween contains only one element, then the array become object and holds the lookup table only for that element: {... lookup table for element 1...}. So probably every other usage of the lookup table gets only the object for a single element. Which means there would be no issue :)

Ps.: For code maintaining purpose, maybe it would be better to make a single element to behave like there are multiple targets. That would free up several if statements, but on the other side you would get some loops if there is only one element. But it would help to reduce the codebase.

 

I tried to simulate that situation, but there were no error with the latest beta version, so it seems fine with multiple targets too: 

See the Pen KLyLLv?editors=0010 by mm00 (@mm00) on CodePen

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