Friebel

I know jack, that's why I removed my post so quickly. I know you guys are working hard and are nice guys and very helpful and I understand debugging other projects takes a lot of work and is not fun. I don't want you guys to do my debugging either. Most of the time I just ask a question here to be sure things didn't change so I'm not running in circles or whatever. But I always want to solve things myself here and don't want to waste your time with that. On the other hand last week I was pretty much debugging gsap itself in the end and it took me a lot of time because there were some nasty things I bumped into. And than it's not so much fun to hear this demo-question all the time and also things like 'nothing has changed in v3', as it was already taking me a lot of time to upgrade and that wouldn't be the case if the issues I've bumped into weren't there. Also in the end a lot DID change and was causing these issues. [edit] Also unfortunately it's not all done. Still struggling with some draggable issues. If I find the time I make a demo, but first I have to figure out why things are not working anymore, while in v2 they were. And if that's some issue in my code (for example made during upgrade) or somehow related to the lib. Also if you look at this exact thread where I was just asking what browsers are supported by gsap and you see I directly received the question to supply a demo again ( @Shrug ¯\_(ツ)_/¯ ) , which is crazy to me if I just ask for what browsers are supported... That to me was like that question is so rusted and brainwashed to some here and I was like; please people, just read the question first and think if you really need a demo. I am working on a lot projects at the same time and after a week of upgrading like 30 projects to gsap v3 I was a little tired of just another issue with it and saw it only in IE11 so the asking for a demo again was the drop for me. But I shouldn't have put that on you and should have thought a little longer before posting. I respect you guys a lot and I think it's great you take questions this seriously and that's great. So that's why I removed my post so quickly. Sorry you saw this, I did remove it because I shouldn't have written that and think longer. And in the end it was my own mistake this time in my code, because during the conversion from v2 to v3 of so many projects I changed in this project the this.draggableThing = Draggble.create()... into this.draggableThing = Draggable.create()[0]. So from an array to a single instance. That's why this.draggableThing[0].endDrag() couldn't be found.

Yes, IE11 reports that 'endrag' on a Draggable is not supported or something like that.

I'm doing some tests on interactives now which are converted to gsap 3 and I wonder; What browsers are actually supported by gsap 3? Thanks in advance,

@OSUblake @ZachSaucier Ah my bad, this was probably a problem with the package-lock.json file. I had it commited to git and pulled the project on another system without running an npm install there, so the lock-file wasn't in sync with the actual installed modules. My bad, I should not check in lock-files. Or run an npm install on the new system to update the node-modules after pulling from git.

@GreenSock Jack, I just tested version 3.2.2 and can confirm this is working as expected now! Thanks for your fast responses and fixes!

@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

After one time using 'npm install gsap@3', which did upgrade gsap from 3.2.0 to 3.2.2, now the 'npm update' is working again. So because I was working around the 'npm update' not working as described above, by using 'install' instead of 'update' to go from 3.2.0 to 3.2.2, now suddenly the update is working again ( @OSUblake : still just with a regular caret) So now I was on gsap 3.2.2 (after the 'hard' install of 3.2.2) and then go back to 3.2.0 with 'npm install gsap@3.2.0' and after that try 'npm update gsap' it does work. So the hard install fixed the issue. So not sure what this was. I never seen this problem before on any of my projects with any of the packages I use. So if nothing is changed on npm/gsap this must have been some cache thing, but it remains odd to me as I even did a complete clean npm install in the end after completely removing the node_packages folder. And that didn't help. Well, whatever does the trick.

No no no. That's not true.

Thanks @GreenSock Jack. I just installed gsap 3.2.2 and there it's working perfectly fine without sack errors! ? [edit] Uh... I meant sTack errors, not sack errors, hahaah ? @GreenSock @ZachSaucier

Just to be sure: you really did 'npm update' (so not npm install gsap@3)? BTW I never had this problem before. Not with gsap, neither with other packages. Other packages (and gsap until now) are upgrading with 'update' perfectly fine, also on this project)

I'm currently having gsap 3.2.0 installed and the latest version on npm now is 3.2.2. But even though the package json says '^3.2.0' behind the 'gsap' dependency, with 'npm update' or 'npm update gsap' the gsap package doesn't update to the latest version. I even completely removed the full node_modules folder and did a fresh 'npm install' with the exising package.json just to be sure and tried 'npm update' and 'npm update gsap' afterwards, but it still doesn't update gsap from 3.2.0 to the latest version. It seems like something is off on npm/gsap. Which is strange to me, as npm/gsap (https://www.npmjs.com/package/gsap) is indeed telling the latest version is 3.2.2. The only way that is working now, is re-installing gsap with 'npm install gsap@3', but I would expect npm update to work as well, as it is not a major version change from 3.2.0 to 3.2.2. Or am I mistaken? "dependencies": { ... "gsap": "^3.2.0" ... }

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?

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.

@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 ? Haha, I understand ?

Using onComplete inside the stagger-object of a tween I want to add parameters to it. But it ignores the onCompleteParams put inside the stagger-object (undefined). Instead, it's using the onCompleteParams of the parent tween. IMHO this is unexpected behaviour, I would expect the stagger-object, with its own onComplete function, to have its own onCompleteParams too. I'm not sure if this is done on purpose, but being able to have a different onCompleteParams inside the staggerobject would make more sense to me. Also, if I'm not overlooking things, being able to use onComplete inside a stagger object is something I read here from @OSUblake (thanks for the tip!), but can't find it in the documentation next to .stagger. Maybe add this information inside the info on .stagger in the documentation? But again, I might be overlooking things as I didn't read everything there is. I would just expect it to be there somewhere, but couldn't find it. (https://greensock.com/docs/v3/GSAP/Tween ) BTW @GreenSock this was one of the reasons why staggers weren't working in a project (I was talking about it previously in another thread).

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)) ...;

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! 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. 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!

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. 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. Great tip. I'm gonna try that one.

So how do you know which methods people use? I for instance use addCallback() a lot. Also I think a migration document doesn't have to include everything that has changed (like the release notes), but IMHO should contain everything that could break existing code, so we know what to migrate. That's why we create migration docs right? I understand you'd like people to move from v2 to v3 and make that transition as small as possible and don't want to scare people so they don't make the transition, but if the transition in the end contains all kinds of extra things we need to migrate next to the migration document (as how it is now) - we have to figure out ourselves -, than it's way more work than expected and that's causing confusion and all these questions on the forum. I understand you made this choice, so I understand this is not a discussion and after a lot of searching I found most of the stuff out now, so for me it's not really an issue anymore, but I just want you to know I respectfully have to disagree and really do think all breaking changes need to be in a migration document. That would have helped me a lot to make the choice to migrate now or on a later stage to gsap 3, or better: be confident enough because of the migration doc that a transition would be easy to make with the information in that document.

Using timeline.tweenTo() is causing a range of maximum stack errors, being showed in the console. I've created a very simplified demo on codepen (see link). This looks like an issue inside version 3 to me as I follow the documentation of v3 and this demo is very reduced to just this and still shows the issue. (Link to docs: https://greensock.com/docs/v3/GSAP/Timeline/tweenTo())

@GreenSock It seems like there are some important things missing from the migration documents (also see previous post). Just found out that gotoAndPlay() is removed (and can be replaced by play()), but I can't find that in the migration guide. I see it in the release notes, but shouldn't this be in the migration guide as well? IMHO that would help people move from v2 to v3 without unexpected surprises.

Alright, addCallback is removed from the API according to the releasenotes and it looks like '.add(function())' is what I'm after. So far this seems to do the job. @GreenSock Shouldn't the removal of addCallback() be in the Migration document too? I might be mistaken, but when I search the document on addCallback I can't find it there which could confuse more people like me.

Thisone for everyone bumping into this thread using gsap v3, using Webpack and don't want to import everything from the PIXI lib, but single 'modules' from PIXI. This works fine with gsap 3 PixiPlugin and it's not a problem if you use registerPIXI() multiple times (per file that imports PixiPlugin); Below code is in ES2015+ import { gsap } from 'gsap/all'; import { PixiPlugin } from 'gsap/PixiPlugin'; import { VERSION as PIXIVERSION, DisplayObject } from 'pixi.js'; gsap.registerPlugin(PixiPlugin); PixiPlugin.registerPIXI({ DisplayObject, VERSION: PIXIVERSION, });

Upgrading projects from v2 to v3 I'm not at a point where gsap doesn't recognise .addCallback() in version 3's timeline object. I can't find anything on that in the migration guide (shouldn't this be in there?) I've tried replacing all 'addCallback()'s to 'call()', which looks the same according to the v3 docs, but that doesn't seem to be the same, as than I suddenly get maximum stack reached errors (so is obviously not being called at the right time / in endless loops). [edit 25-2] The maximum stack errors written about here are from an issue in gsap 3 on timeline.tweenTo(). I've created another thread about this issue here: What is the 'official' direct equivalent in version 3 to addCallback()?

I can't see the problem with that. You write you 'found this on the internet'. This is starting to look like directly copying other peoples creations to me and chosing the easy way here. We all need to learn stuff if we'd want to create things. I might be wrong, but I'm against stealing other peoples work so I'm hoping you don't distribute things like this, maybe slightly changed, as your own instead of creating your own creative stuff. If you like to learn from it and take it as an example, that's fine and great though. Than open the code, try to understand it, trial and error in your projects and read documentation and once in a while ask questions if you cannot figure it out after trying until you get it and can use the framework to create your own stuff to show to the world.