Jump to content
Search Community

Possible GSAP bug switching classNames in Chrome

Conversant test
Moderator Tag

Warning: Please note

This thread was started before GSAP 3 was released. Some information, especially the syntax, may be out of date for GSAP 3. Please see the GSAP 3 migration guide and release notes for more information about how to update the code to GSAP 3's syntax. 

Recommended Posts

In Chrome 74 and Chrome 76 (Canary) with 'disable cache' checked in Dev tools, TweenMax will force a reload on the image animating when the class names are swapped or animating. In addition, there is a weird flicker that happens. The flicker could be a side effect of the force reload. See code pen. The code pen shows vanilla js and jquery working as expected.  You can also look at the network to see the additional (forced) image requests.

 

Note: GSAP's images change because its forcing a reload. Every-time placeimg.com is called, a new random image is returned. 

 

See the Pen mYwJRR by anon (@anon) on CodePen

Edited by Conversant
Code pen appeared blank. Forked pen to show demo.
Link to comment
Share on other sites

Hm, that codepen you provided was totally blank. 

 

I'd love to see a demo because I can't imagine how or why GSAP would force a reload of any images. Feel free to scour GSAP's source code and I think you'll see that it doesn't do anything like that (but please tell me if you find something - maybe I'm missing it). 

 

Any chance you could post a codepen that's not blank? I think there must be a misunderstanding somewhere. 

Link to comment
Share on other sites

Also, for the record, I'd recommend avoiding className tweens because those require looking at literally every...single...CSS property to find anything that has changed between the old and new className, and then tweens each one. It's much better to just specify the properties you want to animate. If all you're doing is swapping classes, it's probably simpler to just use a CSS transition. 

 

Oh, and there is one case where an image's src must get updated internally, and that's for backgroundPosition because it has to measure the width/height of the native image so that it can accurately handle things like percentages. As far as I know, it's impossible to do otherwise. I found the original email notification about this thread and it contained a link to a valid codepen, so I peeked at that and it does indeed look like you've got a backgroundPosition in play there, and it's percentage-based. Perhaps that explains things. 

  • Like 2
Link to comment
Share on other sites

Quote

Any chance you could post a codepen that's not blank? I think there must be a misunderstanding somewhere. 

 

That's very strange. Not sure why it was blank. I forked it. You can view the demo here:

 

Quote

Oh, and there is one case where an image's src must get updated internally, and that's for backgroundPosition because it has to measure the width/height of the native image so that it can accurately handle things like percentages. As far as I know, it's impossible to do otherwise. I found the original email notification about this thread and it contained a link to a valid codepen, so I peeked at that and it does indeed look like you've got a backgroundPosition in play there, and it's percentage-based. Perhaps that explains things. 

I also tried to remove the backgroundPosition in the style to see if that impacts the rendering. It doesn't... same issue.

Link to comment
Share on other sites

I also want to point out I'm not seeing the issue in FireFox when 'Disable Cache' is checked. It seems to be isolated to Chrome.

 

I couldn't duplicate the issue in Chrome 73. It appears something in Chrome 74+ changed.

 

Link to comment
Share on other sites

Chrome did add a built in lazy load for images below the fold of the viewport months ago. I wonder if those new versions is causing a conflict or that buggy re-loading of images. Which would not surprise me based on Chromes track record with not being consistent about features and those features consistent behavior. Based on that lazy load feature in Chrome there have been reports that users with intermittent network connections, images may fail to load when scrolling down the page or trigger a reload. Hopefully they work it out. But you can always submit a bug report to Chrome Developers and see if they can fix your issue. They are pretty good (sometimes) on fixes their bugs.

 

Happy Tweening :)

  • Like 2
  • Haha 1
Link to comment
Share on other sites

Aha! I see the problem. 

 

GSAP does a ton of work to manage conflicts and ensure that things run smoothly even if you interrupt things mid-tween. One of the things it does in the case of a className tween is to see if there's already one running on that element, and clear things properly (which likely involves editing/reverting inline styles). To work around some browser inconsistencies and ensure that things render properly, it records the element's cssText (all the inline styles) and then after it does its work of applying the new class and analyzing the differences in all the properties, it re-applies that cssText. In your case, that entails background-image too but you've actually got a URL that changes the image supplied randomly!  

 

You can get the exact same effect by removing TweenMax altogether and simply doing:

//doesn't change anything, but the browser re-loads the background-image if you've got cache disabled:
elem.style.cssText = elem.style.cssText;

 

I'll add a line to CSSPlugin that only runs that code if the recorded value is different than the current one. Seems to resolve this edge case. You can preview the next version of GSAP (uncompressed) here with that change in place: 

https://s3-us-west-2.amazonaws.com/s.cdpn.io/16327/TweenMax-latest-beta.js

 

Better? 

  • Like 3
Link to comment
Share on other sites

1 hour ago, GreenSock said:

Aha! I see the problem. 

 

GSAP does a ton of work to manage conflicts and ensure that things run smoothly even if you interrupt things mid-tween. One of the things it does in the case of a className tween is to see if there's already one running on that element, and clear things properly (which likely involves editing/reverting inline styles). To work around some browser inconsistencies and ensure that things render properly, it records the element's cssText (all the inline styles) and then after it does its work of applying the new class and analyzing the differences in all the properties, it re-applies that cssText. In your case, that entails background-image too but you've actually got a URL that changes the image supplied randomly!  

 

You can get the exact same effect by removing TweenMax altogether and simply doing:


//doesn't change anything, but the browser re-loads the background-image if you've got cache disabled:
elem.style.cssText = elem.style.cssText;

 

I'll add a line to CSSPlugin that only runs that code if the recorded value is different than the current one. Seems to resolve this edge case. You can preview the next version of GSAP (uncompressed) here with that change in place: 

https://s3-us-west-2.amazonaws.com/s.cdpn.io/16327/TweenMax-latest-beta.js

 

Better? 

Yup! Solves the problem. Thank you for your quick responses. 

  • Like 3
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...