ScrollTrigger enable seems to scrub even after refresh

[emsee]

I'm using ScrollTrigger to, among other things, control webGL. It's working beautifully. However, I'm trying to set up a custom snapping system (ScrollTrigger's snap doesn't meet my needs) and hitting an issue when I disable then enable ScrollTrigger.

 

I'm basically using ScrollTrigger to tween a value from 0-1 which I pass to my camera. When I get close to a certain value (in my codepen example, when I pass 0.1) I want to disable ScrollTrigger and manually tween to a new value. After some gubbins (not included in my pen), I set the scroll position using scroll() and re-enable ScrollTrigger.

 

The problem is that ScrollTrigger seems to jump back to where it was disabled and then tween to the target position all over again!

 

This only happens when I have Scrub enabled. If I set it to 0, there is no problem, but then I lose the nice smooth scrolling in my WebGL.

 

Can anyone please help me prevent this problem?

 

PS: Sorry if my CodePen looks a little odd. I've basically extracted the important code from my app, so the structure is a little funky.

See the Pen BapGgxQ by highlyinteractive (@highlyinteractive) on CodePen

[GreenSock]

Thanks for the reduced test case, @emsee. It is a bit of a tricky scenario.

 

Solution: add these lines after you enable() the ScrollTrigger:

g.scrollTrigger.refresh(); // re-calculates start/end
gsap.set(g, {progress: g.scrollTrigger.progress, overwrite: true}); // sets the progress immediately instead of scrubbing, and overwrites the scrubbing tween

// or you could replace the line above with: gsap.getTweensOf(g)[0].progress(1);

 

When you enable() a ScrollTrigger, it automatically refreshes its start/end values to ensure they're correct, but timelines have to wait one tick to do that (I'll spare you the lengthy explanation, but just ask if you want one). Anyway, when you disabled the ScrollTrigger, it was at a progress of around 0.1 and then when you re-enable it, it must scrub to the new value (0.5) which is what you were seeing. To get the behavior you want, we've gotta basically make the progress jump there instead of tweening there. So we refresh() to ensure the start/end are set correctly, then we directly set the progress and use an overwrite: true in order to overwrite the scrubbing tween. 

 

Does that resolve things for you? 

See the Pen e500c7ad56ff97f35149ba60d194e521 by GreenSock (@GreenSock) on CodePen

[emsee]

Hey Jack,

 

Thanks for your help! This hasn't quite solved the issue, but it's getting closer. The problem now is that scrollTrigger seems to be sending an update with a value close to zero - so essentially the scrollbar briefly jumps to the top of the page, then back to where it should be (which causes all manner of problems in my app).

 

I've updated my pen to show the new problem: 

See the Pen xxgMQxL by highlyinteractive (@highlyinteractive) on CodePen

 

My first thought was to set a boolean to ignore the update while the reset is happening, but that doesn't seem to prevent it.

 

Any ideas what's going on?

[GreenSock]

That's because by default when you disable() a ScrollTrigger, it resets the animation but you can tell it not to reset by passing in false as the first parameter:

g.scrollTrigger.disable(false);

Does that resolve things for you? 

[emsee]

Unless I’m missing something, that doesn’t seem to resolve the issue. 
 

I’ve updated the pen, but it’s still jumping to near zero

[emsee]

That's odd. It was still being problematic on mobile, but now that I've checked on Desktop, it's working fine.

 

Looks like I need to do more testing!

[GreenSock]

Maybe just a cached file?

[emsee]

No, I've tried it using CodePen, and on my local dev environment. It just seems to be glitchy on mobile. On desktop it works perfectly fine.

 

I'm testing on iOS 14.4.2 on an iPhone X.

[GreenSock]

On 4/27/2021 at 2:50 AM, emsee said:

No, I've tried it using CodePen, and on my local dev environment. It just seems to be glitchy on mobile. On desktop it works perfectly fine.

 

I'm testing on iOS 14.4.2 on an iPhone X.

Is there any way you could be more specific?  Better yet, can you isolate things further? It seems like your demo still has a lot going on that could probably be simplified - I just want to make sure we're on the same page about exactly what isn't working the way you think it should. I can't seem to replicate any problem on my iPhone XS, but maybe I'm missing something.