[Fixed in v3.2.1] Issue with CSSPlugin in Firefox: TypeError: oldParent is null

[Friebel]

In a project using gsap 3.2.0 everything works fine in Chrome, MS Edge (the latest chromium version) and even IE11, but CSSPlugin is throwing a TypeError in Firefox only (Both in Firefox: 73.0 as well as in Firefox 73.0.1 64 bits, win 10). Because even IE11 is not showing any errors or warnings and everything is running fine this probably is only related to Firefox in combination with the _getBBoxHack function inside the CSSplugin. Firefox was not having this error when this project was using gsap v2.

 

Because of this errof the project is not even running at all (holds on error) in Firefox, but is running in all other browsers as mentioned 😟

 

Could this be gsap 3 having difficulties in tweening cloned svg elements? (gsap 2 was not having those issues with this project)

Looks like it to me, also see my other post of today where cloned elements are not working the same as the original elements anymore, while in v2 they were.

 

Here's the stack trace:

[ZachSaucier]

Can you please produce a reduced test case where this error is occurring?

[Friebel]

25 minutes ago, ZachSaucier said:

Can you please produce a reduced test case where this error is occurring?

Sorry Zack, I don't have the time for that. I'm upgrading projects to version 3 and this is all taking me way too long now. I'm working for days now to solve issues I'm having when just upgrading from gsap 2 to gsap 3. I thought this upgrade would be painless, but that doesn't seem to be the case. There are more things changed than I thought and I was also bumping into an issue of Draggable, and I did read the migration guide beforehand. I'm also starting to bump into other things right now, like scopes, staggerTo not working anymore (I know we can add stagger: {} to a .to(), but scopes are changed and also the targets in stagger-update-functions and so on which need a different approach in v3 in all these projects. Which is fine, but I didn't expect that because I got the impression by what I read about v3 that this transition should go seamless by just some renaming. Guess I was wrong or misinterpret that. 

 

Don't get me wrong, I understand the choices of v3 and it's a great upgrade. Just underestimated the transition and didn't expect issues to happen, because I never had that before with Greensock. That's all.

[GreenSock]

So sorry to hear about all the headaches, @Friebel. For the VAST majority of projects, migrating to GSAP 3 is quite simple but it sounds like you're doing some pretty advanced stuff (which is great!) and you're running into some edge cases. I'd love to help smooth those out. 

 

The error you're getting indicates that you're trying to animate an SVG that's not even in the DOM (has no parentNode), and Firefox won't report things correctly in that case. That's unrelated to GSAP and it's quite annoying.

 

The _getBBoxHack() method is almost identical in GSAP 2, so I'm very curious to see an example where the identical thing works in v2 but not in v3. Any chance you could provide one? 

 

2 hours ago, Friebel said:

I'm also starting to bump into other things right now, like scopes, staggerTo not working anymore (I know we can add stagger: {} to a .to(), but scopes are changed and also the targets in stagger-update-functions and so on which need a different approach in v3 in all these projects.

When you say "scopes", are you referring to things like onCompleteScope, onStartScope, etc. being consolidated into a single callbackScope? Hopefully that'd actually make your code more concise, but the functionality is still totally there. 

 

What do you mean that staggerTo() doesn't work? I'm not aware of any problems with that legacy method. The only minor change would be that TweenMax.staggerTo() returns a timeline rather than an Array of tweens. I'd definitely call that an improvement. But if you're running into some other problem, please share more details. 

 

You said "and also the targets in stagger-update-functions" - can you clarify what you mean by that? Are you talking about onUpdate in staggers? 

 

Again, I'd love to help. It looks like you've been using the tools since way back in 2013 which is great! Maybe one day we'll even deliver enough value to justify a Club GreenSock membership

[Friebel]

15 hours ago, GreenSock said:

So sorry to hear about all the headaches, @Friebel. For the VAST majority of projects, migrating to GSAP 3 is quite simple but it sounds like you're doing some pretty advanced stuff (which is great!) and you're running into some edge cases. I'd love to help smooth those out.

I think so too

 

15 hours ago, GreenSock said:

The error you're getting indicates that you're trying to animate an SVG that's not even in the DOM (has no parentNode), and Firefox won't report things correctly in that case. That's unrelated to GSAP and it's quite annoying.

I just did some testing and that was the case as you wrote; I set the transformOrigin with gsap.set() to a cloned svg element that was added to the DOM after gsap.set(). Now I reversed the order it's not throwing the error anymore in Firefox and shows the animation fine. Except for that there is a difference in setting the transformOrigin on an object ON the DOM vs an object NOT ON the DOM; I had to use different values for transformOrigin now it's put on the DOM first. Which also explains the issues I had in another thread (I will response there).

 

15 hours ago, GreenSock said:

The _getBBoxHack() method is almost identical in GSAP 2, so I'm very curious to see an example where the identical thing works in v2 but not in v3. Any chance you could provide one?

Maybe that little difference in the method was just the make or brake ingredient in gsap 2, as with gsap 2 it didn't matter if the element was on the dom or not, as the transformOrigin was working anyway on a set() and FireFox didn't complain either.

 

Guess the conclusion is that gsap 3 does things different than gsap 2 causing setting transformOrigin on an object not being on the DOM to fail in Firefox, and to have the wrong outcome with the same transformOrigin in other browsers. In other words; in gsap 2 we could set the transformOrigin to an element not (yet) on the DOM, where in gsap 3 that's not possible anymore.

 

I didn't look into the _getBBoxHack() function, but at first sight it looks like a thing I once noticed ant that's that the original getBBox() js-function is not able to measure DOM elements currently not on the DOM or as I believe even when display is none or even visibility is hidden. I guess you have found a workaround for that with _getBBoxHack()? It would actually be great if you did!

 

15 hours ago, GreenSock said:

When you say "scopes", are you referring to things like onCompleteScope, onStartScope, etc. being consolidated into a single callbackScope? Hopefully that'd actually make your code more concise, but the functionality is still totally there.

I saw callbackScope in the documentation and I like that. The thing I'm talking about here though is the fact that everywhere in ES6 classes 'this' stands for the class-object normally and if we use event functions we normally use arrow functions or bind(this) so this inside that event function is the class/object it is in. But when using gsap event-functions like onUpdate, onComplete etc. that behaviour is different. Well we could still bind(this) to these functions and treat them the same, but to me it's not sure how we could access that tween than or its targets, so so far I couldn't find a way to make that work.

 

To me as a developer this feels counterintuitive in ES6/2015+. Well at least to have 'this' as per default set to the tween. Because there suddenly 'this' stands for the tween it's triggered by but I would rather bind(this) the function and have it set to the class/object it's in as I do everywhere else. As a developer, although I understand why you did it, I find this default confusing and error prone, because it's so different than the rest of the philosophy of ES6/2015+ classes in my opinion. With this we now have to send the real 'this' (so the class/object) as an onUpdateParam to use that inside the onUpdate() function. That works, but now we have the situation that everywhere in the project 'this' is the class/object itself, but suddenly in these event handler-functions 'this' suddenly is a tween. So I find myself adding all kind of warning-comments in my code there to indicate that 'this' is not what I would expect, but the tween instead, and that a 'self' functionparameter I created now is in fact the 'real' 'this'.

 

To me that's the other way around. I'm not sure if we can change that default behaviour (I've believe I've seen it somewhere in the docs, but I might be wrong or forgot where and otherwise we could always use a bind(this) ourselves), but to me as a developer it would make more sense to have that behaviour turned off per default and have the tween-object inside a function parameter. Than we could bind(this) the event handler functions still, like we do everywhere else, and still reach the tween-object with a function parameter.

 

So my question now is this: Am I missing something here and is what I'm after already possible the way gsap 3 is now somehow? Or would it otherwise be possible to add the tween as a parameter to the event-function instead of the other way around (like in gsap 2)? And if there is a config to reverse this behaviour, would it be possible to set that per default to have the tween inside the event function?

 

15 hours ago, GreenSock said:

What do you mean that staggerTo() doesn't work? I'm not aware of any problems with that legacy method. The only minor change would be that TweenMax.staggerTo() returns a timeline rather than an Array of tweens. I'd definitely call that an improvement. But if you're running into some other problem, please share more details.

What I mean with 'staggerTo() doesn't work' is that the staggerTo() method seems to be gone in version 3. At least I had different kind of issues with staggerTo() and when I looked in the v3 docs for staggerTo the search didn't return any results, so I figured 'staggerTo' is gone and needed to be replaced with a .to() with a 'stagger: { each: 0.2 }' inside to have the same behaviour.

 

 

But than I bumped into other issues, like the 'this' as described as above. But also the 'target' I previously used inside event functions like onUpdate(). That seems to be replaced by targets(), but to me it's not clear on staggers how to use that as suddenly there are obviously more targets. So I tried targets()[0] and in some cases that solves the problem, but in other cases not. I'm doing something wrong there, so now the stagger is not staggering anymore, but directly jumps to the end result. That's obviously something I'm doing wrong, but I'm not sure what's the supposed right way of doing things here. But I need to dive in specifically on that point in an isolated project. The reason why I called this in my previous post is not that it's something wrong in gsap, but that it takes time to figure this kind of stuff out to know how it is supposed to work in version 3. That comes with my job, so it's fine, but I just didn't expect that by transitioning from v2 to v3. And is also the reason why I don't have much time to create 'simplified' projects of all these projects I bump into issues. Or at least I wait till it's really necesary. I try to isolate the problems myself in little projects though, but then everything still is (and needs to be) in a fully working development environment with webpack and all that. So that's a lot easier and less time consuming for me.

 

15 hours ago, GreenSock said:

The only minor change would be that TweenMax.staggerTo() returns a timeline rather than an Array of tweens. I'd definitely call that an improvement. But if you're running into some other problem, please share more details.

That sounds like an improvement to me. Not sure though if this influences the usage of event functions like onUpdate() though. But guess that doesn't have an effect on it.

 

15 hours ago, GreenSock said:

You said "and also the targets in stagger-update-functions" - can you clarify what you mean by that? Are you talking about onUpdate in staggers?

Yes. See above.

 

15 hours ago, GreenSock said:

Again, I'd love to help. It looks like you've been using the tools since way back in 2013 which is great! Maybe one day we'll even deliver enough value to justify a Club GreenSock membership

Your help is very much appreciated and yes, I'm using gsap a long time now with a lot of fun and enjoyment every time again and again. Moving to v3 is a little getting used to once, but is definitely a big step up. And I love the improvement in output filesize and the logical way it is setup. And as I wrote in my other thread, yes, I do have an active Greensock membership. And that's absolutely worth it. That way I am also able to use things like MorphSVGPlugin, which I happily do for years now.

 

Looking forward to your reaction about the 'this' and the 'targets' (and maybe your thoughts on setting values to a DOM element not yet connected to the DOM, it would be nice to understand why setting transformOrigin on those work on 'all' browsers, but need different values, except for on FireFox where it's not working at all). Right now it looks like these things are the latest bump to understand moving things to v3 the right way with the projects I'm currently converting. Thanks a lot @GreenSock Jack, Zach etc.!

 

 

[OSUblake]

12 hours ago, Friebel said:

To me as a developer this feels counterintuitive in ES6/2015+. Well at least to have 'this' as per default set to the tween. Because there suddenly 'this' stands for the tween it's triggered by but I would rather bind(this) the function and have it set to the class/object it's in as I do everywhere else.

 

I'm not sure what you mean as the behavior hasn't changed since v2. The animation has always been the default scope of callbacks, but arrow functions cannot be scoped or used with bind.

 

this.tween = gsap.to(".box", {
  x: 100,
  onUpdate: () => {
    console.log(this); // the class
    console.log(this.tween); // the tween
  }
});

 

The only way this will be the tween is when using a regular function, or the new method syntax. And again, this is the same behavior in v2.

 

this.tween = gsap.to(".box", {
  x: 100,
  onUpdate() {
    console.log(this); // the tween
    console.log(this.tween); // undefined
  }
});

 

12 hours ago, Friebel said:

What I mean with 'staggerTo() doesn't work' is that the staggerTo() method seems to be gone in version 3.

 

It will still work for backwards compatibility, but it's been deprecated. Using the stagger property is the correct way to do staggers now as it gives you more options. If you look at the source code, you'll see that staggerTo converts it to the new syntax.

 

//ONLY for backward compatibility! Maybe delete?
staggerTo(targets, duration, vars, stagger, position, onCompleteAll, onCompleteAllParams) {
  vars.duration = duration;
  vars.stagger = vars.stagger || stagger;
  vars.onComplete = onCompleteAll;
  vars.onCompleteParams = onCompleteAllParams;
  vars.parent = this;
  new Tween(targets, vars, _parsePosition(this, position));
  return this;
}

 

If you need the current element being animated, put the callback inside a stagger object.

 

gsap.to(elements, {
  x: 100,
  stagger: {
    each: 0.2,
    onUpdate() {
      console.log(this.targets()[0]); // the current element
    }
  },
  onUpdate() {
    console.log(this.targets()[0]); // the first element
  }
});

 

12 hours ago, Friebel said:

Guess the conclusion is that gsap 3 does things different than gsap 2 causing setting transformOrigin on an object not being on the DOM to fail in Firefox, and to have the wrong outcome with the same transformOrigin in other browsers. In other words; in gsap 2 we could set the transformOrigin to an element not (yet) on the DOM, where in gsap 3 that's not possible anymore.

 

I know you have to work to do, but making simple demos of your upgrade issues would be much faster than explaining the problem, and having us guess at what the problem is. This demo shows an obvious bug that @GreenSock needs to look at.

 

In Firefox, setting a transform/origin on an element outside of the DOM doesn't get rid of the temp <svg> element. Inspect the red rect. It's inside a different <svg> element.

 

See the Pen c468d76d9075f1b57c04fca1ec1fbd58 by osublake (@osublake) on CodePen

 

 

12 hours ago, Friebel said:

and to have the wrong outcome with the same transformOrigin in other browsers

 

If you inspect an SVG element that you set the transform origin on, you'll see that it will actually be 0px 0px 0px. This is because gsap bakes transform origin into the matrix, so when you copy/clone a transformed SVG element, GSAP can't get back the original transform values. In v2, gsap saved some info on some attributes to help extrapolate the original transforms from the matrix.

 

To understand why gsap bakes the origin into the matrix, here's an excellent article written by Jack.

https://css-tricks.com/svg-animation-on-css-transforms/

 

To restore the original transform in v3, I would just remove the transform attribute and set the transforms again. 

 

See the Pen 895238a8976ab8608750a0824f785ae8 by osublake (@osublake) on CodePen

 

 

[GreenSock]

8 hours ago, OSUblake said:

This demo shows an obvious bug that @GreenSock needs to look at.

 

In Firefox, setting a transform/origin on an element outside of the DOM doesn't get rid of the temp <svg> element. Inspect the red rect. It's inside a different <svg> element.

Ah, perfect reduced test case! Thanks so much, @OSUblake. That should be resolved in the next release which you can preview at https://s3-us-west-2.amazonaws.com/s.cdpn.io/16327/gsap-latest-beta.min.js

 

@Friebel I bet that fix will resolve the positioning issues you were having as well. I also worked around the Firefox limitation related to SVG elements that aren't in the DOM yet. There's yet another Firefox bug that won't report the bounding box correctly in that scenario. Again, that updated version has a workaround in place. Please kick the tires and see if it all works well for you. 

 

As for the scope stuff, I think Blake covered that all very well. No changes to that were made in that regard since v2. We can't put a tween instance into the parameters elegantly because it'd conflict with stuff like onUpdateParams, etc. 

 

18 hours ago, Friebel said:

That seems to be replaced by targets(), but to me it's not clear on staggers how to use that as suddenly there are obviously more targets. So I tried targets()[0] and in some cases that solves the problem, but in other cases not.

Yep, WAAAY back when I first created GSAP, it was only designed for a single target but obviously in modern times with query selectors, we must accommodate multiple targets, hence the move to "targets()". That should be a pretty straightforward change. In the context of staggers, notice the advice Blake gave - if you want a per-sub-tween callback like onUpdate, put it INSIDE the stagger object. Then your this.targets() will only have ONE element because it's getting added to each sub-tween instead of the parent (stagger) tween. I hope that makes sense. 

 

19 hours ago, Friebel said:

Your help is very much appreciated and yes, I'm using gsap a long time now with a lot of fun and enjoyment every time again and again. Moving to v3 is a little getting used to once, but is definitely a big step up. And I love the improvement in output filesize and the logical way it is setup. And as I wrote in my other thread, yes, I do have an active Greensock membership. And that's absolutely worth it. That way I am also able to use things like MorphSVGPlugin, which I happily do for years now.

Ah, that's great to hear. Thanks so much, @Friebel. 

[Friebel]

On 2/23/2020 at 8:31 PM, OSUblake said:

Using the stagger property is the correct way to do staggers now as it gives you more options. If you look at the source code, you'll see that staggerTo converts it to the new syntax. If you need the current element being animated, put the callback inside a stagger object.

I see indeed staggerTo() still exists. I opened this thread a few days ago with the error I got then and was convinced staggerTo() was gone, but can't really tell the message I saw in the console.log() anymore, sorry. Should have made a screenshot. Moved on to upgrade another project, and by now have more knowledge about v3 changes and have seen other things that needed to be changed with the stagger code in that project, so maybe it was another issue at play here causing problems with staggerTo(). I converted the code to stager: {} anyway as I always like it better to move to the new than to stick with the old deprecated stuff. I'll give it another try.

 

On 2/23/2020 at 8:31 PM, OSUblake said:

I know you have to work to do, but making simple demos of your upgrade issues would be much faster than explaining the problem, and having us guess at what the problem is.

I have to respectfully dissagree on that. On big projects where everything can influence each other (cloneNode, Draggable, MorphSVG etc. for instance inside the same svg group) - especially on frontend work where browsers change a lot -, where the issue is not yet narrowed down to the core, it is impossible to create a simple demo to show the issue as it could be many things. As with these kind of strange and unexpected behaviour it's hard to tell where it's coming from until narrowed down a lot after a lot of tracing and testing.

Of coarse at this time now, after all the groundwork, it's easy to create a reduced demo, because I already narrowed down the issue to where it somewhat takes place; not being on the DOM vs being on the DOM and/or related to cloneNode(). So your reduced demo couldn't be created earlier on for the reason described above. So I also don't agree with you that you would have figured this out sooner, as there's no way I could have created a reduced demo before I had narrowed down this issue (which was in fact a stack of different issues together, as you have seen in my thread, a few of them issues in the gsap lib itself that needed to be solved - but also browser-related stuff -, like inside the Draggable plugin, but we couldn't know that upfront and could in the beginning all be related). And I never send the real/full projects. So in the end I think this was the fastest way to solve this.

 

In threads I'm opening about the transition to v3 I see this a lot: 'this behaviour didn't change in gsap 3'. But in the end a lot of things DID change or have issues. Both of them are ok and comes with the job of development and it's a fairly new version, but I don't believe it helps anybody telling 'nothing has changed' upfront, since obviously something did change as the outcome is different. And it also proved to be on some issues in the end. Yes, I can also make mistakes, but to tell upfront nothing has changed gives me the feeling not being taken seriously when opening a thread. I don't open threads for fun. Also by now I hope you understand that last days I found some issues in the gsap lib and in the documentation and so I also helped bugfixing the lib. Which has taken me a long time I'd rather have spent on other things. I am not here to talk bad about gsap and I don't feel that way at all either, I'm here with the same reason as you guys: making gsap better and v3 stable and upgrading everything to v3 so my projects are up to date again, but also trying to help others with the things I found during that process. Like telling you what I think is missing in the docs, what IMHO can make this transition easier for others.

 

On 2/23/2020 at 8:31 PM, OSUblake said:

If you need the current element being animated, put the callback inside a stagger object.

Great tip. I'm gonna try that one.

 

 

 

[Friebel]

On 2/24/2020 at 5:22 AM, GreenSock said:

 

@Friebel I bet that fix will resolve the positioning issues you were having as well. I also worked around the Firefox limitation related to SVG elements that aren't in the DOM yet. 

Great! Ofcoarse it's silly to animate objects that are not on the dom, but to be able to use gsap.set() could make sense. Thanks for the quick action!

 

On 2/24/2020 at 5:22 AM, GreenSock said:

As for the scope stuff, I think Blake covered that all very well. No changes to that were made in that regard since v2. We can't put a tween instance into the parameters elegantly because it'd conflict with stuff like onUpdateParams, etc. 

I'm working on other things right now so don't have this in memory now, but I will take a closer look at a later time and come back to this when needed.

 

On 2/24/2020 at 5:22 AM, GreenSock said:

Yep, WAAAY back when I first created GSAP, it was only designed for a single target but obviously in modern times with query selectors, we must accommodate multiple targets, hence the move to "targets()". That should be a pretty straightforward change. In the context of staggers, notice the advice Blake gave - if you want a per-sub-tween callback like onUpdate, put it INSIDE the stagger object. Then your this.targets() will only have ONE element because it's getting added to each sub-tween instead of the parent (stagger) tween. I hope that makes sense. 

Yes, that makes sense and I like the decision in having arrays instead. Also with this I don't have the stagger-thing in my head now, as I skipped that to upgrade other projects to v3 first, but maybe I will take a closer look at it at a later time and come back to this when needed.

 

Thanks for all you guys help!

[Friebel]

On 2/24/2020 at 5:22 AM, GreenSock said:

As for the scope stuff, I think Blake covered that all very well. No changes to that were made in that regard since v2. We can't put a tween instance into the parameters elegantly because it'd conflict with stuff like onUpdateParams, etc. 

Just a quick thing about scopes that looks the same; at this moment I'm upgrading a project with .addPause() inside timelines and a callback with that. And that's definitely changed in v3. Before the .addPause() in the callback had a parameter for 'this' and therefore inside the function 'this' was a pointer to the parent class, but in v3 'this' stands for the tween (probably because the scope-parameter in .addPause() has been dropped in v3). So after the upgrade to v3 I needed to .bind(this) these functions to be able to reach the 'this' of the class again (ES6/ES2015+).

 

previously this was the function call (v2):

this.tl

   ...

   .addPause('+=0.01', this.onTurned, null, this)

   ...;

 

now I do this (v3) to make 'this' the class it's in

this.tl

   ...

   .addPause('+=0.01', this.onTurned.bind(this))

   ...;

 

[OSUblake]

1 hour ago, Friebel said:

In threads I'm opening about the transition to v3 I see this a lot: 'this behaviour didn't change in gsap 3'. But in the end a lot of things DID change or have issues.

 

If someone says the behavior hasn't changed, that does not guarantee that it is bug free or that new edge cases haven't been introduced. It's impossible to anticipate how everyone will use a brand new code base. 

 

I'm kind of surprised that no one has run into your issues as v3 has been out for several months now.

 

 

1 hour ago, Friebel said:

I have to respectfully dissagree on that. On big projects where everything can influence each other (cloneNode, Draggable, MorphSVG etc. for instance inside the same svg group) - especially on frontend work where browsers change a lot -, where the issue is not yet narrowed down to the core, it is impossible to create a simple demo to show the issue as it could be many things.

 

I dunno. I mean you have the stack trace, and you can insert break points, so I don't see why it would be hard to isolate the problem down to a reduced test case. GSAP is a just library, so you control when and how it gets called.

 

But even if you can't reproduce the error, a simplified demo still goes a long way. Just seeing what you are doing is super helpful as it gives us a jumping off point to test different theories out. And logic errors are very common, so it's hard to rule that out without seeing some code.

 

1 hour ago, Friebel said:

And I never send the real/full projects.

 

We would never ask for a full project. We just want to see the problem. The less code, the better. 😁

 

[Friebel]

@OSUblake the problem I'm facing a lot since v3 is that the stack trace is all inside gsap itself, most of the time doesn't trace back to a function inside my own code. At least not in the trace inside the error message. I didn't try console.trace() yet, which might I will try next time. Maybe that shows a longer trace. 

For example when gsap reports some variable is missing and thinks (and writes in the console) that's because a plugin is missing, it only shows the key it expects inside an object, but it doesn't show a trace to where that key is actually expected. When having lots of tweens inside the project (in some of the projects here that is the case), especially with the same name of keys, it's pretty hard to find the point where it is missing a key. And this is actually the most easiest thing to solve compared to some other issues occurred recently. 

 

That said, I think there has been a lot of progress these days in finding these things. With all you guys quick responses and great help I think we tackled some nasty ones. And I'm actually working on the last (pretty big) project now to upgrade to gsap v3 and have one one other project open with one issue that @Greensock will look at tomorrow to fix. Next to this I've already upgraded 21 (!!) projects this and last week to gsap 3 now. So still some things to be solved left, but I call that progress! And everything that's fixed now will be fixed forever 😀

 

1 hour ago, OSUblake said:

We would never ask for a full project. We just want to see the problem. The less code, the better. 😁

 

Haha, I understand 😀

[Friebel]

1 hour ago, OSUblake said:

I'm kind of surprised that no one has run into your issues as v3 has been out for several months now.

To be honest; me too. Either some developers don't report things and make it work with workarounds without telling, but I expect many developers with big projects still use v2 instead of spending time to convert it to gsap 3 just yet. It's pretty jung still. If I new it would be this much work I probably have waited too. But now that I'm almost finished I'm actually glad that it's all in gsap 3. It's definitely an improvement and with the findings fixed (and/or knowledge of v3) the better.

[Friebel]

On 2/23/2020 at 8:31 PM, OSUblake said:

I'm not sure what you mean as the behavior hasn't changed since v2. The animation has always been the default scope of callbacks, but arrow functions cannot be scoped or used with bind.

The only way this will be the tween is when using a regular function, or the new method syntax. And again, this is the same behavior in v2.

About scope in callbacks: Are we on the same page here? (also @GreenSock and @ZachSaucier )

 

I always want 'this' to be the main class, so I had this in v2:

class Something {
  
  constructor() {
    // ...
    
    this.tl
      .staggerTo(arr, 0.001, {
        LEDdata: lD,
        ease: Linear.easeNone,
        onComplete: this.onLUpd.bind(this),
        onCompleteParams: ['{self}'],
      }, 
      0.1);
  }


  onLUpd(tween) {
    // HERE 'tween' IS THE TWEEN (the {self}) AND 'this' IS THE CLASS/OBJECT THE TIMELINE IS IN
  }
}

 

and needed to change it into this in v3, 'cause I can't find a way to keep using 'this' for the main class. So it's the other way around:

class Something {
  
  constructor() {
    // ...
    this.tl
      .to(arr,
          0.001,
          {
            LEDdata: lD,
            ease: Linear.easeNone,
            onCompleteParams: [this], // (for now? would expect this to be inside the stagger-object. see other thread)
            stagger: {
              each: 0.1,
              onComplete: this.onLUpd,
            },
          });
  }

  onLUpd(self) {
    // HERE 'self' IS THE CLASS/OBJECT THE TIMELINE IS IN AND 'this' IS THE TWEEN,
    // SO IT'S THE OTHER WAY AROUND
  }
}

 

So this shows to me the workings are different in v3 vs v2. To be able to have both access to the main class as well as the tween I got the feeling I needed to turn the process the other way around: add the main class reference as an onCompleteParam and keep the 'this' on the tween.

 

(BTW I can bind(this) the callback function onLUpd() and in given example use this.tl to reach the timeline, but in reality the tl is in fact an array of timelines and next to that I need to have access to a tween or a single stagger-tweens too.)

 

But what I actually would like to be able to do is what I did with gsap v2: having the 'this' inside the callback for the main class, and add the tween itself as a function parameter to the callback. As I would like 'this' to be the main class/object always. Is that possible?

[OSUblake]

Oh, I see. Yes, that '{self}' string option was removed because it really didn't seem necessary. Maybe Jack can add it back in?

[ZachSaucier]

Not the cleanest solution, but you could use .bind() to do this:

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

[GreenSock]

4 hours ago, OSUblake said:

Oh, I see. Yes, that '{self}' string option was removed because it really didn't seem necessary. Maybe Jack can add it back in?

If the goal is to have a reference to your class instance as well as a reference to the tween instance...and my goal is to keep GSAP as small as possible...wouldn't the best overall solution be to do what @Friebel mentioned above and do this?: 

gsap.to(... {
  onCompleteParams: [this],
  onComplete: function(myObject) {
    console.log(this); // tween
    console.log(myObject); // class instance
  }
});

Or better yet, just make yourself a little helper function to automate that: 

// this function will always push the tween instance into the parameters for you and allow you to define a scope. 
function callback(func, params, scope) {
  let tween;
  params = params || [];
  return function() {
    if (!tween) {
      tween = this;
      params.push(tween);
    }
    func.apply(scope || tween, params);
  };
}

And then the usage would look like: 

gsap.to(... {
  onComplete: callback(tween => {
    console.log(this); // since this is an arrow function, scope is locked anyway so this is your class instance
    console.log(tween); // tween instance
  })
}); 

The helper function gives you ultimate flexibility; define any scope, pass in any parameters, or just use arrow functions naturally and have the tween instance always passed in as a parameter by default. I didn't test any of that code but hopefully it at least illustrates the concept properly. 

 

Almost nobody used the "{self}" special param thing in the v1/v2 days, so I'm just not inclined to add more kb to GSAP and slow down parsing for something that can easily be accomplished with a helper function like above. See what I mean? 

 

Does that help at all? 

[Friebel]

@GreenSock Jack, I can confirm this issue is fixed in v3.2.2. As I see this fix being mentioned near v3.2.1 I'm sure it's fixed in that version too, so just put that in the title of the thread. Thanks!

 

BTW, nice we can now safely use cloneNode again too with respect to the transformOrigins!! Nice