Gsap markers position not working on scroll+refresh | versions > 3.12.2
samuel-clara opened this issue · comments
The current version of gsap ScrollTrigger 3.12.5 and also versions after 3.12.2 seem to not correctly handle trigger markers when refreshing the browser window after scrolling to a different position then the top of the page. With gsap ScrollTrigger 3.12.2 all is working fine.
If I load a page, scroll after the trigger element, refresh the browser window and scroll back to the top, the start marker changes it's position. I add two screenshots of first load and load after scroll down.
I've tried to create a basic codepen for this but codepen does not maintain the scroll position after refresh so it's impossible to recreate this on codepen.
Hm, I can't seem to reproduce this problem and nobody else has reported such a thing - would you mind providing a CodePen demo even if it's not possible to actually see the issue in CodePen's normal iframe-based mode? We can test it in CodePen's "debug" view (I think a paid package is required to do that on CodePen, but it's fine if you don't have it - we can test in ours). It just really helps to see your setup, as there must be something that's different about your setup than what we're trying on our end to reproduce it.
And you're saying that the actual problem isn't really the markers themselves - it's miscalculating the ScrollTrigger start/end positions (even with markers disabled), right?
Thanks!
I found the problem, I was using this seemingly innocuous line of css:
html { scroll-behavior: smooth; }
Hm, I'd love to see your demo. Typically ScrollTrigger forces scroll-behavior to "auto" but maybe you overrode that?
The reason scroll-behavior: smooth is so problematic is that it's sorta like setting a CSS transition on something you're animating with JS; when the JS sets the new style on every tick, the browser is like "NOPE! I'm not gonna apply that right away...I'm gonna gradually do it over time" which totally gets in the way and also hurts performance. Part of what ScrollTrigger must do is temporarily set the scroll position to the very top in order to properly do all calculations especially with any pinning, and then it restores the original scroll position. So scroll-behavior: smooth would basically mean the browser says "NOPE!" when ScrollTrigger moves the scroll position temporarily.
Does that clear things up? I'm still curious to see a demo if you're willing to provide one.
No I didn't overrode that, and strangely it works with ScrollTrigger 3.12.2. Thanks for your explanation, this clears things up for me. Maybe scroll-behavior is not forced by ScrollTrigger.
Here a codepen with a simpler situation which however behaves in the same way locally on Chrome 121.0.6167.139 (on codepen I'm not able to reproduce it do to the iframe-based mode), when I scroll to the end of the document, refresh and then scroll up the hero does not show up. When I remove the scroll-behavior line it works fine.
https://codepen.io/meteorit/pen/yLwEper
I noticed now this just happens on Chrome with dev tools open.
Hm, I can't get that to happen at all, anywhere, even in Chrome with Dev Tools open. Not locally, not in debug mode in CodePen...I must be missing something.
Well, if you have any other clues as to how to reproduce it, I'm all ears, but I'm glad to hear you've got things resolved now.
Seems to happen only with "Disable Cache" activated in Chrome Dev Tools "Network" tab.
Very confused about that.
Yeah, I can't reproduce that even with "Disable Cache" enabled in the network tab.
Sorry, I know this is closed but just wanted to say thanks and also that I've just been stumped by this problem.
I had the exact same issue that my "scroll-behavior: smooth" on the html element was causing my pinned element to miscalculate it's start and end triggers when refreshing the page.
This was on a very simple:
ScrollTrigger.create({ trigger: ".pinned-background", start: "top top", end: "bottom bottom", pin: ".left", });
I noticied that if you refreshed the page outside of the triggers view ( most top part of site say ) it would likely be fine. That makes good sense above regarding what scroll behavior is doing, so likely is clashing.
Can also confirm that downgrading to 3.12.2 worked whilst leaving the scroll behavior on.
Hi @themorgansmake - do you have a minimal demo illustrating the issue (like a CodePen or Stackblitz)? And are you saying that the latest version of ScrollTrigger/GSAP does NOT work the way you'd expect? It is definitely not a good idea to have scroll-behavior: smooth on a site that's using ScrollTrigger. Or at least disable that when doing a ScrollTrigger.refresh().