Steve Giorgi

Yea, the scrollbar is replaced with a custom scrollbar in the site --- it is very jarring. OK, it does work great if you're going through it forwards/backwards in the actual build which mimics the triggers here. I added the overflow hidden just so that if a forum user scrolled through the little Codepen preview window too quickly, they wouldn't think the overlapping there was the issue I was trying to demonstrate. My mistake, that worked against me. I am only seeing overlapping when the browser is resized. Maybe I'm just completely misunderstanding how ScrollTriggers should be used. I wanted to show an animation + text, pause, allow the user to trigger the next animation + text, pause, and so on. If I change all of my ScrollTriggers to scrub, and run through it, nothing overlaps or conflicts, so the durations are correct. The only issue is when resizing. Maybe I'll simply disable the default resizing and handle it some other way.

Thanks Blake, That's interesting though - I wish I could see how they were conflicting. If I have panels dedicated to triggering the animations, and each runs it's course before the next panel comes into the viewport I thought it wouldn't be possible for them to conflict. I understand if it's a logic issue, but would you mind pointing out where one of the logic issues is? I looked at the post you referred and he definitely has conflicting tweens. Each of my triggers is a dedicated 100vh panel, the start times should never touch. I'll check to see how duration works, that must be where I'm confused. I must have been looking at it for so long that I'm blinded to it. I'll review; at least that gives me a huge hint. Thank you.

The ScrollTrigger stop and end markers reset to the bottom/top of the screen each time I resize or anytime something triggers a refresh. I've tried to save and restore the ScrollTrigger progress. I've also tried to do this after disabling all autoRefreshEvents, but some events still trigger a refresh: ScrollTrigger.config({ autoRefreshEvents: '', }) window.addEventListener('resize', () => { allProgress.current = allScrollTriggers.current.map((st) => st.scroll()) allScrollTriggers.current.forEach((trigger, i) => { trigger.scroll(allProgress.current[i]) }) }) The markers associated with the ScrollTrigger/timeline+tween that is firing are well off the top of the screen -- the trigger is two full screens from the top of the viewport. I'm thinking the Codepen does not trigger the ScrollTriggers on resize because it's in an iframe?

I have some fairly complex animations what I'm triggering with dummy containers so that I can have them separated by 100vh sections. It's a little cumbersome but it works very well for the most part. I created each ScrollTrigger as a stand alone trigger in the demo on purpose -- I'm using those as my timelines which include many different tweens with the actual build. In this example, I just added a text blurb to each. Now this demo appears to work correctly --- although it doesn't appear to be triggering the ScrollTrigger resize listener (I may be wrong but I don't see it triggered when I resize Codepen); these containers/triggers are always set at 100vh. I have this same exact type of layout built in Gatsby.js and when I scroll through it, it works beautifully, but when I resize the window after I've triggered a couple of the animations, text controlled by separate dummy triggers (the '.scroll-trigger' containers in the demo markup) will overlap. In my setup, trigger1 and trigger2 will both get tripped on resize so that the text and other elements overlap (if I scrolled further, trigger 2 and 3 gets tripped, etc.). I thought it was the two separate tweens that are attached to trigger2, but in fact it's the tween in trigger1 that is being tripped along with trigger2. The trigger (trigger1) start points are already above the viewport, yet it's tween is being tripped on resize. I've tried to set an end for each trigger, invalidate the triggers on refresh, set immediateRender: false, refresh and update all of the ScrollTriggers on resize. Edit: I added overflow hidden to each trigger --- didn't want any confusion when multiple triggers got hit in the small Codepen preview. I'm just hoping someone has some ideas. I know it's difficult if the demo works but maybe the markup structure or something else would point to something very obvious that I'm not seeing.

Where can the latest ScrollTrigger beta be accessed? I saw a version of it from June here in the forums but wasn't sure if this could be found elsewhere.

Thank you very much for taking the time to have a look and come up with some solutions. I can definitely think outside of not disabling/enabling the ScrollTriggers but the animations do rely on triggered animations rather than scrubbed. I think your first option will work for both types! Your second option is extremely clever --- I could see that working with/without scrubbed animations. I don't think either solution relies on the animations being scrubbed, right? Both solutions really make me start to think outside of the "box". For instance, instead of snapping position in a carousel to combat someone scrolling too quickly, we could snap the position based on velocity. Thank you Jack. Edit: This was very testable --- your idea about velocity checks is really exciting. Got ahead myself. It looks like both options will work with triggered animations as well.

I'm just wondering if this is normal behavior. If it is, then I'll figure out a way to get the user to the correct position when they hit an anchor. Storing the scroll position before the ScrollTriggers are enabled and restoring the position sends the viewport to an incorrect position (incorrect in the sense that the saved position is somehow not the same when the triggers are re-enabled). It ends up pinning/triggering the other ScrollTriggers around it. I wasn't able to replicate the secondary issues I described -- pretty sure it's a logic issue on my part.

Firstly, I'm trying to create demos for anything I post -- I know that's key to giving you guys something to go on. Would it work to create a demo in Codeasndbox in this case? I was kindly asked to avoid it but I'm not sure I can replicate this behavior on Codepen. If so, I'll attempt to replicate there. This occurs on screen resize and hot refresh in Gatsby.js: The ScrollTrigger (is this simply a result of invalidateRefresh?) This is wrapped in a useEffect with an empty dependency: tlEnergyTransition1.current = gsap .timeline({ paused: true, scrollTrigger: { trigger: scrollContainer2Ref.current, start: 'center center', toggleActions: 'play none none reverse', invalidateOnRefresh: true, }, })

@GreenSock thanks Jack, that clarifies several questions. I didn't realize I could set everything to a fixed height and hide the overflow -- I thought that would impact how ScrollTrigger behaves. That makes it much easier to calculate the position in different scenarios. I also see revert and refresh options are part of the self.enable() function but I didn't see those documented. @OSUblake I created as minimal of a Codepen demo as possible. I'm pretty sure this behavior is correct but I'm trying to find a work around for anchors. Within each section would be many other ScrollTriggers with their own timelines; each section is pinned for the duration of those animations. I also tried Jack's suggestion -- I am able to save and set a scrollTo position with overwrite: "all", after re-enabling the ScrollTriggers and it does move the viewport to that position (the position is off due to paddingBottom but this can be calculated/accounted for other ways), but several of the ScrollTriggers end up firing (timelines become overlapped). I looked at the self.enable function -- the viewport is reset when self.enabled is set to true; but as you know that's tied to a ton of logic. I'm hoping to just toggle the ScrollTriggers off, move the viewport, toggle them back on so the current section (and all other sections) continue pinning. Use case would be for anchors and other functionality that might require going through all of the ScrollTriggers very quickly --- another example: scroll to top button. https://codepen.io/steve-giorgi/pen/jOmeBwK I'm forking the demo to see if I can replicate the behavior described above when saving/restoring the position.

I wonder if this wasn't working because I pasted a link to a specific component: https://codesandbox.io/s/sleepy-cdn-9f3sm I tried creating this same demo in Codepen but I don't have access to the same hooks. I'm trying to replicate the behavior without the React stuff.

Does the ScrollTrigger pinning add spacing to the entire document or is the spacing isolated the the div that is created on the fly? Does your vertical scroll position change when the ScrollTriggers are active/inactive -- obviously it changes within the section you're pinning but how about outside of it?

I think it's the expected behavior, just in my scenario it works against me. OK, I'll grab the position after I've disabled the ScrollTriggers and moved my window/viewport with the ScrollTo anchors. I will then enable the ScrollTriggers and manually set the position to the position stored right before the ScrollTriggers were re-enabled; this sounds very logical. Thank you. I think this kind of sums up the issue I'm seeing: I have several ScrollTriggers which creates scroll distance for the pinning to take place. I disable them, I move my window position with ScrollTo to one of the containers but all of the distance has also been removed (since the ScrollTriggers have been disarmed). I enable the ScrollTriggers and it moves my window/viewport relative to where it was previously, which is way up the page and nowhere near where my anchor dropped me. This sounds like correct behavior to me --- but, then, how can we account for anchor links --- in my case, the pinning has to be disabled because the scrollTo action hits those ScrollTriggers causing the animation to run through very quickly running to the end and sometimes overlapping/breaking. I'll see if I can move my demo over to CodePen. It took several hours to build the current demo (thank you both for trying to have a look).

@GreenSock I updated to version 3.7.1. Now, let me preface this by saying I only broke out each ScrollTrigger to mimic my current project --- each has it's own set number of pinned screens to scroll through and other parameters that make each unique in the actual project. I also have dummy containers which trigger several ScrollTriggers within each section; I mimicked that here as best as possible without making it too convoluted. The dummy containers were Carl's recommendation and it does work really well --- in the context of this demo they don't make sense but I wanted to be sure to get them in there to mimic the overall setup. I made it as simple as possible and broke everything out so that it's very clear. https://codesandbox.io/s/sleepy-cdn-9f3sm?file=/src/pages/index.js If you scroll through it and click on an anchor it will jump to the correct section and immediately jump back. This may be the correct behavior for how I'm toggling the ScrollTriggers off/on but as an end user it's difficult for me to know that for sure. If you disable the onComplete: line 180 and click on an anchor; it works as expected. In the context of anchors or at least in my application of them, you'd want to move the user to that section and then re-enable the ScrollTriggers so that they can continue through the animations contained in that section.

I'm using 3.7.0. I'll update now. I have 35 ScrollTriggers on one page within my current project. I'm iterating through all and disabling. Firing a window position with ScrollToPlugin and re-enabling all ScrollTriggers. Disabling works beautifully, ScrollToPlugin works beautifully, but upon enabling them, the viewport snaps right back to the original position and/or to the very top of the page. I'll see if I can pin down the same behavior with a few ScrollTriggers in Codepen. I was hoping I could pass a parameter to .pause() or .enable() --- something simple to keep the viewport at the new location.

Re-enabling disabled ScrollTriggers after the scroll position has changed returns the viewport to the original position. Can ScrollTriggers be re-enabled without having the viewport be reset?