Friebel

@GreenSock Jack, I'm very dissapointed right now. The beta version where you had fixed this issue was working fine, but in the released 3.2.5 version (both the standard npm version as well as the bonus package) there are new bugs again which are even worse: making the reverse not doing anything anymore and even crashing the full animation with stutters and flahses and all. I cannot even describe it. This is definitely not a caching issue of pnpm or any other issue here besides gsap. I removed all the pnpm cache, removed the node_modules folder, removed the pnpm lock-file and re-installed everything. But still the released gsap 3.2.5 is having issues that weren't there in the beta version. I even stepped away from pnpm for this project completely just to be sure this is not an issue of pnpm or windows, and went back to npm, which is reliable for years and never let me down. So removed the full node_modules folder of the project and re-installed everything from scratch in this project with `npm install`. With this I am absolutely sure the new gsap package is installed inside the project and this isn't some cache thing. After switching back to the beta everything works again. So it's definitely an issue in the released 3.2.5 version. What's the use of supplying a beta version to test if things are changed for the worse in the release?? Last weeks I found a lot of nasty bugs in the lib to a point I really wonder if you even test the lib as these issues are so on the surface. You call these rare cases every time I report one, but I highly doubt these are rare cases. To be honest I am really getting tired of debugging gsap now and I am done with it. I reverted to the beta version and go look for alternatives. Maybe build a lib myself. That cost me way less time than continues debugging a library I even pay for and by people expecting me to debug issues in the lib they created. Sorry to say, but I pay for gsap to not having to build it myself and don't need to do this myself so I have time to focus on other things, but this costs me so much time and money now to a point I would have created an animation-lib myself for the things I need. I have other things to do and I'm debugging these issues for weeks now. Sorry to say, but it seems like quality control is not what I was used to with greensock. Which is a shame. I feel very dissapointed and I already know how you would react to this. Which makes it even worse. I'm done

Hi @GreenSock Jack, I ran this code to view the gsap.version and it stated 3.2.4. Which is weird and makes me worried a little bit, because I definitely installed the latest beta version you sent me with success (the console also ended with 3.2.5 installed) and even tested the installed version number afterwards by running `pnpm list gsap`, which showed 3.2.5. Crazy. I now removed the full node_modules folder and did a install from the package.json again. Now it works with no problem. So this was indeed some crazy pnpm cache problem. You say you are confused, but I am as well now. This makes no sense to me. Last week I switched from npm to pnpm (and also than removed the node_modules folder and re-installed everything, but with pnpm), which is not copying the same modules to every project, but uses things like symlinks for optimization and re-use of modules so it doesn't have to download the same modules everywhere. I wonder if we can fully rely on pnpm and/or if it has something to do with some nasty explorer/win10 issues I'm facing like freezing and sometimes not refreshing explorer-windows since the 2 latest windows 10 updates. My system is clean, secure and fully up to date for sure. Hope that Microsoft will fix these issues soon, as I'm not the only one having these or that I can find a way to somehow solve this or work around myself. But not sure if that's related to this caching issue. Guess I can at least not trust the pnpm install to always work. And not even the pnpm list command obviously. Crazy. On the other hand, a week or two ago I had also a caching problem with npm and gsap, as we found out in these forums. Before that I never experienced any caching issues with npm or yarn and I'm using these for years now. So I'm confused. So I guess I need to always remove the full node_modules folder now and than running an install, just to install something new to upgrade, which is definitely not the way it should be obviously. Not sure what's causing this. Sorry for this inconvenience. Obviously the 3.2.5 beta fixes the original issue. Thanks for your time and pointing me to gsap.version. That's a nice one to know. Glad it is fixed now in 3.2.5 and guess it's safe to release.

You already have it. It's in this thread already. I even created both an example using gsap v2 as well as an example using gsap v3. This already IS the demo. What else do you need? As said, in my project I'm doing the exact same thing as done in the example here. The only thing I changed is the update eventhandler, as you did in the changed codepen. But I've checked everything several times now and can't get it to work with the tgz-file you supplied. Eventhough the code should be exactly the same as in the codepen. But, as said, the only difference is that in the 'real' project I'm using a position in the play() and reverse() methods to play from. Are you sure that should also work with the latest beta? I see the minified javascript file (gsap.min.js) inside the tgz package you've sent is the same as the one you use in the codepen. But are you sure also the tgz package contains exactly the same individual module files as well as used in the minified js you use in the codepen? As I'm importing via webpack imports and don't use the minified file. Also please keep in mind this project worked for years with all gsap v2 versions. I see you only changed one thing (the ctrl update function) in the example. So that should also be the only thing I need to change in the real project to make it work in v3 as per logic, I'd think.

Thanks for the tgz file. Unfortunately this is not fixing the issue in the project here. Still weird things happen with the reverse. The first time reversing is okay, so something has changed, but all next times I press the button to reverse it moves forward again. There is a difference between the simplified codepen I posted and the code I'm using in the actual project though; and that is that in the codepen I just use play() on the animTl without parameters, but in the actual project I add a position to play from. [edit] This was just a quick test. At the moment I don't have much time to dive into this further. So I'm not sure if I'm missing something that I need to check or change in my code or that the new gsap is still having an issue in reverse when using a position parameter in the play() and reverse() methods. But wanted to give you already this information above.

So if I get what you're saying there's only one timeline of one second in your example. And when the totalTime progresses internally the totalTime gets recalculated to a position on the one second timeline, either by moving forward or moving backward, depending on the current state of the yoyo repeat: forward or backward. Do I get that right? If so, why wouldn't that be possible with an endless loop (repeat: -1) where yoyo is false and the timeline is playing in reverse? Isn't that the same as repeating the backwards part of a yoyo loop? So to explain this in your example, let's say we're setting the one second timeline now to { repeat: -1, yoyo: false } and playing it in reverse with reverse() or timeScale(-1). I don't really understand why the inner workings of a timeline progression would be handled differently for non-yoyo loops vs yoyo-loops. Wouldn't it be possible to calculate the totalTime internally to a position on the reversed timeline as well? So like the yoyo internal re-calculation, but now running in backwards state when timescale is below 0 and forward state when timescale is above 0?

Ah, that clears things up Great extra catch! Thanks a lot for this! ? That really helps! I'm sure it won't affect many peoples code in a negative way, because when someone found and uses timeScale I think they also know what they're doing and will understand and be glad with this decision! I'm using gsap via npm and webpack, so to test the minified version in the actual project I have to change the structure too much. So as I've seen it working in the codepen, I just wait for the upcoming release and use it via npm. Looking forward to this next version! Thanks again for the quick action!

@GreenSock Thanks a lot for this great in depth explanation Jack. I understand your challenges. Out of curiosity: how do you do it with yoyo than? Or does yoyo work because when it is reversing it always have played once?

@GreenSock I created two codepens. One where I use gsap v2 and one in which I use gsap v3. These simplified demos show the issue I'm facing right now after upgrading. As you can see the animation is perfectly working in version 2, but the expected reverse when hitting the 'OUT' button is not working in version 3 with the exact same code. As you can see in the second demo (using gsap 3) the box is not moving back, but forward when hitting the 'OUT' button. BTW, I wasn't talking about right or wrong or smart/stupid, but about consistent logic vs inconsisant logic and thinking for a developer that uses the lib vs trusting developers and giving them freedom. Seems like my point didn't come across. Demo with gsap 2: https://codepen.io/Friksel/pen/oNXqdKp Same demo with gsap 3: https://codepen.io/Friksel/pen/bGdvYrR

@GreenSock Alright, just looked inside the project and unfortunately resume() isn't a solution here, as I need to play from a labels position with play('label'). So unfortunately the issue persists. [edit] Would it be possible to ad an optional function parameter to resume() to be able to set the timeline position to resume from? Just like in the play() method? So without that parameter resume() works as it does now (as I understand it is like play, but except from the logic to reset the timescale/direction), but can be used with a resume-position (like a label) as well.

Alright, just looked inside the project and unfortunately resume() isn't a solution here, as I need to play from a labels position with play('label'). So unfortunately the issue persists

@ZachSaucier Thanks for pointing to that thread. Also here, as written in another thread I just reacted, I think the same; I am a little dissapointed that the same logic doesn't apply everywhere and that the libs obviously thinks for itself and makes the decission for us developers in that something is 'wrong' and corrects it automatically. I don't really like that as we might not be wrong in doing something, but do it on purpose. As in this case. The use case I use this in I described above. And I think that's a pretty great reason to make a zero timescale work. So I am dissapointed about these decisions. [edit] BTW, if there are people that on purpose wet a timeScale to 0 and than expect the playhead to move when setting play() and complain if it doesn't move then those are not great developers to begin with. On the other hand I do think that if you set a timescale to 0 you might expect the playhead to stay still when using play() and are allowed to complain if it changed the timescale by itself and moves the playhead, eventhough the developer set the timescale on purpose to zero. That said, like I wrote in the other timeline, I will try if resume() is a solution for the issue I'm having in this project now.

Thanks for your response @GreenSock Jack. Reason I'm coming with these issues is because things related to reverse a timeline direction as made on gsap v2 don't work anymore in v3 (it doesn't reverse). So now I'm figure out why and find these sub issues. I don't really like it when a lib thinks for me on what should happen, to prevent a 'mistake' for me and therefore gets out of the way of other logic as how it is build. I would say that if play() respects the height of the timeScale value, what it does rightnow, than it would be logical to also respect it if a value is zero or negative. When that's not the case I understand it could prevent some problems for other people, but it can also cause issues when things are not working as expected, because it's not using the same logic in every case. So now that's error prone to people understanding the logic, because the logic is not the same everywhere. I would in these cases chose for the same logic everywhere and trust developers on their responsibility a little more. That said; resume() could be a nice alternative though in this case. I will try that out

When timescale is set to 2 and we call play() directly after that, play() respects the value of timescale and plays twice the speed. When timeScale() is set to 0 and we call play() directly after that, play() doesn't respect the value of timescale and resets timescale to 1 and plays. To me this is not logical and inconsistant behaviour. I would expect the play() method to always respect the timeScale() value and never change it. So if we set a timeScale to zero, we do that on purpose. If we than call play() after that we do that on purpose also, because we would like to put the animation in play-mode, but for example like to tween the timeScale in to go gradually from 0 to 1.

When setting a negative timescale to let play() play in the reverse direction, the play() method resets the direction and always plays forward. I understand the difference between play() and reverse() and that play() is there to normally play forward and reverse() to do play in the reverse direction, but when setting a negative timescale the whole thing should reverse in my opinion. So if we set a negative timescale and run play() I would expect the play head to play from the current position backwards and reverse() from the current position forwards. The way I would expect this to work: - set the timescale to a negative value to run the thing backwards when play() is called: - on a call of play() just play the direction that is currently set; so backwards - on a call of reverse() play the animation in the reversed direction, which is forwards in this case, as the timescale is set to a negative value

I just edited my post and see your reaction now telling what I just saw, so that was a crosspost You state this is expected. But it's not expected at all to me and doesn't make sense to me either, so I don't agree with you. We tell a timeline to repeat endlessly, so it should repeat endlessly. No matter the direction it's running in. In my world an endless loop means endless loop. Independent of a direction. Just look at how yoyo loops work. Also endless yoyo loops, runing back and forth, run in two directions and never stop. To me this is really an issue in the lib the way it is now.

While creating a codepen thing of another issue with reverse() I am now experiencing while converting projects from gsap 2 to 3 I just bump into another issue which is there when putting a negative timescale value on an endless looping timeline (repeat: -1). What happens? When the timeline loops in normal direction it repeats endless as expected. But when setting a negative timescale to the timeline the timeline stops running after some repeats. Of course this is not what we might expect, as the loop should keep repeating endlessly, only in a different playhead direction. This looks pretty random, so I made a video of this codepen to see it in action (used browser: Ms Edge Chromium version), but this forum doesn't let me upload the file here because of the filesize, even if I make a very low resolution mp4. ? So guess you have to try the codepen and by patient to see it happen sometimes and other times not. It looks like a pretty random issue, although happening a lot. [edit] It is actually not that random; what seems to happen is that when reversing the direction, it will now only reverse the actually done repeats when it was playing forward. So if we first let the playhead run a timelinesequence three times (so one normal run and two repeats) and then hit enter a negative timescale to reverse the direction, it only runs three times the sequence in the reversed direction and then stops. But instead it should keep repeating endlessly, as the repeat is still set to -1 to have an endless repeating loop. Seen in both gsap 3.2.0 as well as in 3.2.4.

The demo you supply now does work in Firefox. The Draggable file you posted before didn't solve the issue by replacing the Draggable on the codepen with the new Draggable, as I wrote above. I think it's a pitty you don't trust me in clearing cache. I'm only a senior developer with over 20 years of experience. But that feeling I'm getting more often here lately. To the point I'm starting to wonder why I still post these bug issues in gsap here.

I just tried the new Draggable you posted by overwriting the Draggable in the codepen, but it still doesn't work in Firefox.

So you want to proof something is running or not running in Internet Explorer and now you make a codepen as a demo? First, to come on this forum in IE11, the Greensock website throws an error in IE11, because it's using 'foreach' which IE11 doesn't support (no offense at all to greensock btw, maybe the site just doesn't support ie11). Than, when clicking through that to visit your demo on codepen, codepen doesn't even run in IE. Not from within this forum and not when we go directly to the site. It tells us it's an 'Unsupported browser' and doesn't show us anything more. Codepen just doesn't work in IE. Maybe if you have a PRO version you can use it, but I don't have it and my guess is you don't either. So what's your point? Also, you are talking about the old Edge which is not supported anymore and it is replace with the same name (Edge) by the Chromium version? Sorry, but the old Edge is totally irrelevant now. Espectially when every modern browsers has auto update these days. On topic again please: there's an issue in Draggable that needs to be fixed. See my previous post for a direction. Have a nice weekend!

Not sure if this is the problem, but I see at least one line in the Draggable code that doesn't look right: _isTouchDevice = "ontouchstart" in _docElement && "orientation" in _win; Recently browsers have changed. I had to convert all my projects because of that, so that's why I know. We can't do this anymore: if ('ontouchstart' in window) { // has touch } Because 'ontouchstart' is removed in some browsers. I believe that's in chromium, but it might be Firefox (as well?) where it was. Detecting if a browser supports touch events cannot be done that way anymore. Now we need to detect if touch is supported in other ways. Like using a try, catch around an actual addEventlistener and see if it is ok or catches an error. That might be causing this issue in Draggable. At least the line mentioned above looks outdated to me. (line 796 in Draggable.js)

Yes they do. Sorry, what you write just isn't true. Not sure why you really think that. All my interactives run perfectly fine in both IE11 as well as Edge with both touch as mouse, while not using 'pointer'-events. The latter (Edge) even is just Chromium nowadays, so that's not having any problems whatsoever in this area. Really, 'pointer'-events always have been the troublesome kid. Not touch. Nor mouse. BTW, the link you include in your post is from the year 2014... it's 2020 now, so that's 6 (!!) years ago. We all know that that's 99 years in front-end terms.

@OSUblake That's part of the reason in all projects here I removed all 'pointer'-event listeners two weeks ago. I only use mouse events and touch events now. Support for pointer-events always have been troublesome across browsers. Reading the caniuse page, I'm glad I did that! ? BTW that was also important for event handling priority order; in all browsers touch comes first and than mouse. So when a user uses touch, we can preventDefault() to prevent the mouse handlers to trigger as well. But when using pointer events, they come even before touch, which messes things up in the flow.

I can also confirm that in Firefox for Android 68.5.0 it is still working. I don't know how version numbers go with Firefox cross devices, because on Windows Firefox the latest is 73.0.1 and on my Android device it's still at 68.5.0. I just looked for updates on Android, but Google Play store doesn't show me any updates. So for now this seems to be a Firefox for Windows (and mac?) or desktop only issue. Or maybe the issue is there on Android Firefox 73.0.1 too, but that version isn't released yet?! [edit] I've changed the title

That's what I wrote in the post; Windows. Windows 10. Firefox 73.0.1

Having problems with touch on some projects that are using Draggable I am now diving into this. I'm having problems with touch on both rotating draggables as well as translating draggables on several browsers, but Firefox seems to be the most problematic one. This thread though is about a particular draggable issue that only seem to affect Firefox, while other browsers seem to work fine: The codepen included here is, as you can see, as easy as it can get. A svg circle where Draggable is put on with inertia and rotation. Touch in this example is running fine in browsers like Chrome and Ms Edge (chromium based browsers), but touch is not working at all in Firefox (Windows) here. In the codepen I used the actual gsap template from this forum, which is still using version 3.2.3, but I've also seen this beviour in version 3.2.4 locally here. [edit] the touchstart seem to be triggering something in draggable though, because when just moving the mouse after trying to drag with touch, the object gets dragged, eventhough none of the mousebuttons are pressed. Also this issue occurs with Draggable type set to 'x,y' as well as set to 'rotation'