Jump to content
Search Community

Logo ScrollTrigger Translate (+ Pin) breaks on resize in Chrome (but works in Codepen)

TheSylvester test
Moderator Tag

Go to solution Solved by TheSylvester,

Recommended Posts

I'm trying to make a super simple behaviour and found that Chrome is breaking ScrollTrigger scrub revert positioning on maximize / some resizing.  Everything looks perfect in Codepen, but when I launch it from Webstorm and view it on Chrome, resize, and especially maximize, causes crazy behaviours like remembering the wrong initial values, etc.  Sometimes the values are so off the element disappears.  I've tried everything from ScrollTrigger.clearMemory() to invalidateOnRefresh, added a 500ms setTimeout to the resize (I've tried without), removing the initial CSS transforms and using a gsap.set at the beginning of my useEffect, using a .fromTo() with the initial transform in the from var, and any combination of the above through exhaustive googling for 2 days now.  The only thing I can do is to window.location.reload() on resize which totally works but I'm not really sure if that's the best way forward here because I wonder if that will just completely mess with iOS as I heard it calls resizing on just a normal scroll (I don't own an iPhone).

 

I know it's weird to troubleshoot since Codepen works, but if someone could send me in the right direction, or kindly take the time to verify this outside of Codepen and let me know I'm not crazy?

See the Pen zYLBZba by thesylvester (@thesylvester) on CodePen

Link to comment
Share on other sites

Hi @TheSylvester it is indeed hard to understand that problem, but it looks similar/related to the one I'm having right now. I'm rather sure you are not crazy, at least not more than I am. There seems to be something off with ScrollTrigger and resizing.
It is likely that Jack @GreenSock will swoop in with his magic cape billowing behind him, and his explanation will humble us mere humans - until then, rest assured that you are not crazy, but simply human—if there is a difference that is…

Link to comment
Share on other sites

Welcome to the forums, @TheSylvester. Sorry to hear about the trouble! Sounds like you've put in a lot of effort trying to figure it out on your own. What's particularly frustrating is that it works in CodePen fine, right? 

 

A few questions for you:

  1. Is there ANY way we can reproduce the issue in CodePen/CodeSandbox/Stackblitz? Any tricks? It's just super hard to troubleshoot when we can't reproduce it. 
  2. Did you make sure you're using the same version of the GSAP files in the CodePen and your "broken" version? Any other differences? 
  3. Have you tried removing React from the equation? I noticed you're not doing proper cleanup in React. I'd STRONGLY recommend reading this article:
    gsap.context() is your new best friend in React, trust me. It's so convenient. 

Once we can reproduce the issue, I'm sure it'll become much more apparent what the issue may be. Right now I suspect something with React and improper cleanup. 

  • Like 1
Link to comment
Share on other sites

1 hour ago, GreenSock said:

ANY way we can reproduce the issue in CodePen/CodeSandbox/Stackblitz?

The only thing I can think of is maybe the PRO Live mode in CodePen might do it?  The behaviour only happens in Chrome, and might have something to do with how Chrome will stretch out the layout viewport (and make 100vw / window.innerWidth NOT the width of the window, but instead of the width [or height] of all your elements) if you have any items pushed outside the window bounds on an orientation shift or large resize (like a maximize), so you can cause window.innerWidth to end up being larger than window.outerWidth to hillarious results.  Firefox does not do this.  I suspect the bad behaviour won't happen inside any sort of sandboxed environment because it's contained in a frame, which is why I suggested maybe Live [PRO] mode, which I don't have access to.

 

On my part I will work with the React cleanup and gsap.context and see if it improves the situation.

Link to comment
Share on other sites

One other thing I just noticed is that you're animating the SAME element that you're pinning. That's almost always a very bad idea. Pinning requires some very specific (and sometimes complex) styling, so it's almost always a much better idea to just create a wrapper element and use that as the trigger/pin, and then animate the child itself. In other words, don't pin an element AND animate its properties with another ScrollTrigger. 

 

Once we can reproduce the problem (I still can't seem to), the issue may become more clear.

  • Like 1
Link to comment
Share on other sites

I've learned much from the articles and issues you've pointed out, and in my React code I am now using matchMedia for the context and proper cleanup in my useEffect.  I was able to recreate the problem in plain javascript embedded in an html file, see the attached test file.  Kindly run it in Chrome, in F12 dev tools select iPhone SE, go to page 2, and change the orientation two or three times, and you'll see it evidenced in the console log (the reported size is incorrect) and when you flip back to page 1.  (edit: it's specifically when you're on page 2 with the tagline in horizontal mode, then flip the orientation to vertical)  I have no idea where to put revert or cleanup code in a plain javascript, but I'm almost sure that has nothing to do with it.

 

This has been driving me nuts and I thought I was losing my mind, or just really bad at this.  But I'm now convinced it's not me.

 

 

test.html

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.
×
×
  • Create New...