[undefined in params breaks animation - Regression between 3.1.1 and 3.2.0]

BTW - I think some warning or error message on bad value types could also be useful

[undefined in params breaks animation - Regression between 3.1.1 and 3.2.0]

Thanks a lot Jack for the quick reply

 

If you are saying that the previous behaviour is limited to a limited group of cases, that it is less of an issue to fix some places in the code (we don't use skew that much )

 

Thanks again

Tom.

[undefined in params breaks animation - Regression between 3.1.1 and 3.2.0]

Hi @GreenSock

I upgraded GSAP version in our project and some animations stopped working.

I managed to reduce it to afromTo that had an undefined value in the from params.

It used to work in 2.x and in 3.1.x but since 3.2.0 (and in the current 3.4.2) the animation fails.

 

One can say - "just don't have undefined fields in your code"

but as coding goes, it's not that simple and will require some serious refactoring on our part which I would prefer to avoid.

 

Working demo (GSAP 3.1.1) - 

 

Failing demo (GSAP 3.2.0) -

See the Pen VwegBKR by tombigel (@tombigel) on CodePen

See the Pen OJMdwRV by tombigel (@tombigel) on CodePen

[animation with clearProps value of 'transformOrigin' clears entire transform]

I found a bug with clearProps and opened a ticket on github a couple of days ago - https://github.com/greensock/GSAP/issues/393

I just don't know if anyone is looking at the issues there, so posting here too.

See the Pen RwrVVMg by tombigel (@tombigel) on CodePen

[After upgrading from 1.18.2 to 1.19.0 got a requireJS error for TweenLite]

Apologies for bumping the issue,

Just need to know - Jack, are you planning on addressing this? or do you consider it an acceptable behavior?

Should I wait for another version?

[After upgrading from 1.18.2 to 1.19.0 got a requireJS error for TweenLite]

Thanks Jack.

For your question - yes, once I add TweenLite to the paths of my require config looks like everything works fine.

[After upgrading from 1.18.2 to 1.19.0 got a requireJS error for TweenLite]

TL;DR

I upgraded our project to use 1.19.0 after using 1.18.2 and requirejs couldn't find TweenLite unless I defined it explicitly in the require config paths object.

Is it the expected behavior?

 

 

 

We do amd with requirejs.

My GSAP section in the paths object looks like this (there is also a base url defined of our external libs server):

paths: {
            //  ...
            TweenMax: {min: serviceURL('tweenmax/1.19.0/minified/TweenMax.min'), source: serviceURL('tweenmax/1.19.0/uncompressed/TweenMax')},
            TimelineMax: {min: serviceURL('tweenmax/1.19.0/minified/TweenMax.min'), source: serviceURL('tweenmax/1.19.0/uncompressed/TweenMax')},
            ScrollToPlugin: {min: serviceURL('tweenmax/1.19.0/minified/plugins/ScrollToPlugin.min'), source: serviceURL('tweenmax/1.19.0/uncompressed/plugins/ScrollToPlugin')},
            DrawSVGPlugin: {min: serviceURL('tweenmax/1.19.0/minified/plugins/DrawSVGPlugin.min'), source: serviceURL('tweenmax/1.19.0/uncompressed/plugins/DrawSVGPlugin')},
            // ...
}

This setup worked for a long time now without changing anything but version numbers up until 1.18.2.

After changing the paths to 1.19.0 I got a console error by reuirejs saying it got 404 on TweenLite because it tried to load it from localhost -

require.min.js:34   GET http://localhost/TweenLite.js 

The way to overcome it was to add a line in paths for TweenLite too

TweenLite: {min: serviceURL('tweenmax/1.19.0/minified/TweenMax.min'), source: serviceURL('tweenmax/1.19.0/uncompressed/TweenMax')},

Is it an expected behavior? Is it a bug? Am I missing something in the require config?

 

Thanks.

Tom.

[Draggable 1.18.5 update() missbehaves]

Posted a bug report on Github, linking it here too.

https://github.com/greensock/GreenSock-JS/issues/154

See the Pen XKderr by tombigel (@tombigel) on CodePen

[Following up on will-change]

Hi, following up on a year old topic 

http://greensock.com/forums/topic/9790-will-change-property/

 

The will-change property is getting some traction lately, it is supported by 3 out of the 5 major browsers and is considered by MS Edge.

 

I was wandering if any work or research was done about adding support (manual or automatic) to GSAP for this?

 

A nice video demo by a google dev demonstrating the performance implications will-change can have:

 

Thanks

Tom B.

[Bug Report: with rotate(180deg) TweenMax sometimes does the wrong matrix conversion]

yes , in the latest preview it seems to be solved.      

[Bug Report: with rotate(180deg) TweenMax sometimes does the wrong matrix conversion]

another case that make a wired mirror flip (happens on production version)

IE 11 , an element with transform rotate of 91 degrees and applying animation to 90 degrees rotation.

 

See the Pen qEObbR by yanivz (@yanivz) on CodePen

[Bug Report: with rotate(180deg) TweenMax sometimes does the wrong matrix conversion]

I have tested 1.14.5_preview5 version for the above scenario.

 

the issue exists..  

On Webkit/Gecko when translateZ value = 0 (reproducible on previous version when Z > 0)

On IE 11 it seems ok.

 

See the Pen XJbyxr by yanivz (@yanivz) on CodePen

 

 

Yaniv

[Chrome and clearprops:"transform" unexpected behavior]

My example was wrong. I meant inline style of course.

someElement.style.transform = 'rotate(30deg)'
someElement.style.webkitTransform = 'rotate(30deg)'

[Chrome and clearprops:"transform" unexpected behavior]

I came across an unexpected behaviour:

apparently Chrome 36 and up supports both prefixed and unprefixed 'transform' property.

 

So, if you set initial transform values on an element (not with GSAP) like so:

someElement {
    -webkit-transform:rotate(30deg);
    transform:rotate(30deg)
}

and do

TweenMax.set(someElement, {clearProps: 'transforms'})

only the unprefixed version is being cleared and the rotation remains on the element.