Jump to content
GreenSock

Search In
  • More options...
Find results that contain...
Find results in...
sebh

ScrollTrigger seemingly inconsistently updates timeline calls

Recommended Posts

Hey guys,

 

 

we've been able to achieve some amazing results using ScrollTrigger on our last project, thanks for the great work.

 

However, two (probably related) issues arose, which I've successfully replicated on this pen. As you can see, we had to mix scrubbed animations with non-scrubbed animations. To achieve that, we've been using timeline.call (which then checks the current scroll direction). When you reload the page (i.e. the scroll bar is not at the beginning, but let's say in the middle of the timeline), you will notice that the called animations are not correctly updated. If you head over to the debug view (https://cdpn.io/sebh/debug/MWorgga/gaMeYdjwPRRM) and scroll right to the point which triggers the green box animation, then reload the page, you'll be able to scroll past it's animation without if ever being triggered.

 

Interestingly enough, this issue no longer occurs if you comment out the last ("regular", i.e. scrubbed) animation (box-5). This leads right to the second issue we encountered. If you comment out the last animation you will notice that the previous (a called, aka non-scrubbed) animation no longer properly reverses.

 

Well, I hope I did a half-decent job in explaining the issues. Thank you for your time.

 

Edit: Please note that the attached pin on the thread doesn't work properly (probably because I used vh). Please open the pen in a separate tab.

 

See the Pen MWorgga by sebh (@sebh) on CodePen

Link to comment
Share on other sites

Hey Sebh -

I've taken a look at your pen and I can't recreate the first behaviour you've described.

(screen recording included for clarity)

 

In terms of the call at the end of the timeline -

.call() functions only fire when the playhead reaches them - Not when the playhead leaves them. 

If you have a callback at the end of a timeline it will play when the playhead hits the end of the timeline, but if you reverse() the timeline, the call() won't fire a second time. 

 

This is by design but obviously not ideal for your use case. 

If you need to call an animation at the end of the timeline you could use the timeline's onComplete and onReverseComplete callbacks? Or potentially use dummy tweens and callbacks instead of .call()

like so?...

See the Pen dyRJyrG?editors=1011 by GreenSock (@GreenSock) on CodePen



One small note - there's also no need to do the following - you can just add tweens to a timeline by using the timeline name instead of 'gsap'
 

// not necessary
timeline.add(gsap.to('.box-1', {
  xPercent: 20
}), 1);

// better
timeline.to('.box-1', {
  xPercent: 20
}, 1);


I hope this helps!

 

  • Like 1
Link to comment
Share on other sites

Hey Cassie,

 

thanks for the swift reply!

 

Using a dummy tween to play the animation works like a charm, cheers!

 

Regarding the other issue: The animation will only be skipped, if the last entry in the timeline is not a call too (sounds really weird, I know, but I wasn't able to find any other way to replicate the behaviour). I've edited the pen to ensure that the last timeline entry is not a call. Incidentally, your "workaround" also solves the other issue. If you could be so kind to try my pen again to replicate? A call being skipped still sounds like a bug to me. I've attached a recording.

 

 

 

Link to comment
Share on other sites

Hey again,

 

upon further investigation it turned out that the fix actually doesn't work. Well, at least not 100% of the time. To illustrate, I created another pen, only difference being that I added an additional section (https://cdpn.io/sebh/debug/OJgzRzZ/XxkVwKBojZoM). With that 3rd section, I am able to once again replicate the issue (see attached recording in my previous post).

Link to comment
Share on other sites

Looks very promising, thanks for the update. I wasn't able to replicate the aforementioned issue anymore. However, I was getting an exception which wasn't there before:

 

scrolltrigger-exc.thumb.jpg.0d61e49634c370a39853cebc9733d2a8.jpg

 

Another, related issue I discovered yesterday: When using a call (or in this case, a fake tween which calls another tween) placed at position: 0, scrolling all the way back up won't trigger onReverseComplete. See this new pen (which uses the updated ScrollTrigger.min.js) for an example:

See the Pen jOwZNYE by sebh (@sebh) on CodePen

Link to comment
Share on other sites

9 hours ago, sebh said:

I was getting an exception which wasn't there before:

Should be fixed now. https://assets.codepen.io/16327/ScrollTrigger.min.js (again, clear cache)

 

9 hours ago, sebh said:

When using a call (or in this case, a fake tween which calls another tween) placed at position: 0, scrolling all the way back up won't trigger onReverseComplete.

Yep, that's actually by design. When you have a pinned ScrollTrigger that starts at exactly 0, it sets it to -0.001 because otherwise it'd get unpinned when you scroll all the way up. That can look a little funky to pin/unpin at the very top like that because the browser handles scrolling on a different thread, thus things jumping back and forth between position: fixed can be very slightly out of sync with repaints. 

It's a pretty easy fix for your case: 

start: "top -1", // instead of "top top"

-OR- just offset that initial tween slightly from the very start: 

timeline.to({}, {
  onComplete: () => box2Animation.play(),
  onReverseComplete: () => box2Animation.reverse()
}, 0.01);

Does that clear things up? 

  • Thanks 1
Link to comment
Share on other sites

19 hours ago, GreenSock said:

When you have a pinned ScrollTrigger that starts at exactly 0, it sets it to -0.001 because otherwise it'd get unpinned when you scroll all the way up.

This is a really good little bit of insight to store away!

  • Like 1
Link to comment
Share on other sites

On 9/17/2021 at 6:47 PM, GreenSock said:

Yep, that's actually by design. When you have a pinned ScrollTrigger that starts at exactly 0, it sets it to -0.001 because otherwise it'd get unpinned when you scroll all the way up. That can look a little funky to pin/unpin at the very top like that because the browser handles scrolling on a different thread, thus things jumping back and forth between position: fixed can be very slightly out of sync with repaints. 

Thanks for the clarification. I noticed ScrollTrigger setting it to -0.001 while debugging and have been working around it by setting the start to "top -1" (just as you suggested yourself). The other issue is resolved with the latest version you posted, thanks!

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