ScrollTrigger not triggering in live but works everywhere else

[Saleem Beg]

This is a really weird one. As you can see in codepen, it works exactly as expected, as well as locally.

 

But on live, for some reason, gsap manages to position the elements appropriately and set autoAlpha to 0, but ScrollTrigger simply does not trigger when the start marker enters the view. The start and end markers appear fine but nothing seems to animate.

 

There are no errors in the console, so I have no idea what could be causing this.

 

Has anyone come across this before?

See the Pen podEqPB by saleemepoch (@saleemepoch) on CodePen

[mikel]

Hey @Saleem Beg,

 

I can't find any elements with class '.fade-in' or '.from-right' ... in your HTML.

So nothing can animate.

 

Happy tweening ...

Mikel

[Saleem Beg]

Hey @mikel

 

There is an image at the bottom with both classes in them. If you scroll down it does animate perfectly. The only trouble is, it doesn't animate on Live, despite all the markers appearing.

[mikel]

Hey @Saleem Beg,

 

Sorry, I have not seen.

 

You need some space to see the effect.

 

body{
  height:500vh; //e.g.
}

 

Happy tweening ...

Mikel

[Saleem Beg]

I intentionally kept the image under the text so the scroll triggers the animation. The animation works perfectly well in codepen, but for some reason, live website is the only issue.

[mikel]

Hey,

 

It's difficult to analyze something you can't see.
If a case works in the CodePen, then it should also run live - unless you have made any changes or other influences there.

 

 

[Saleem Beg]

exactly, that's why I've been wracking my brains over it and can't think of anything that might be different.

 

Literally, it's a push to the repo, and pull from the server, and npm run build, and everything works fine, no errors given.

 

Refresh the browser and the animations just don't kick in when markers come into view. bizarre. The only thing that's different is the domain name and an SSL certificate.

[Cassie]

If you open dev tools can you see any inline styles being added to the image in your live version?

[Saleem Beg]

Hi Cassey,

 

Yes. Here is the screenshot from live. As you can see this is set to pre-animation state (from).

 

I believe your screenshot shows post-animation state (to).

[GreenSock]

It's super difficult to troubleshoot a live site (that's not something we offer for free in these forums because there are just way too many factors involved) but my best guess from a cursory glance is that your elements are starting off (like from the CSS) with an opacity of 0. Notice that you're using a .from() tween, thus it's like saying "use the current value as the END value, and animate to there from the value I'm providing in this tween". Thus if your elements start out at an opacity of 0 and then you do a gsap.from(...{autoAlpha: 0}) that means they're gonna animate from an opacity of 0 to an opacity of 0 (no change)

 

Be very careful about logic issues when you use gsap.from(). They catch a lot of people (one of the common mistakes). 

[Saleem Beg]

Hey @GreenSock / Jack

 

Thanks for the reply.  This is certainly not an issue with logic, else it also wouldn't work in codepen or locally. The code locally is exactly the same as code in live. I am using webpack to compile tailwind, alpinejs and gsap. I commit and push it to the repo, and pull it on the live server and then npm run build.

 

I also placed the following before gsap.from as suggested:

console.log(gsap.getProperty(element, "opacity"));

And the opacity for all ten items is set to 1. Then gsap makes it 0 and fails to animate it back to 1.

 

The markers are clearly visible, but as you scroll down with dev tools open, you will see that the right elements are being targeted, but the visibility just doesn't change.

 

As you can see here, there is nothing else responsible for the elements' opacity and visibility, except gsap's inline styles.

 

 

I would reluctantly share the live link here for all the curious minds to look into this mystery.

https://teque.co.uk/projects/

Here is the readable app.js:

https://teque.co.uk/wp-content/themes/teque/assets/build/js/app.js

 

And here is the relevant part:

const fade_in = gsap__WEBPACK_IMPORTED_MODULE_0__["gsap"].utils.toArray('.fade-in');
fade_in.forEach(element => {
  var x = 0;
  var y = 0;

  if (element.classList.contains('from-left')) {
    x = -200;
    y = 50;
  } else if (element.classList.contains('from-right')) {
    x = 100;
    y = 50;
  }

  console.log(gsap__WEBPACK_IMPORTED_MODULE_0__["gsap"].getProperty(element, "opacity")); // var delay = element.dataset.delay;

  gsap__WEBPACK_IMPORTED_MODULE_0__["gsap"].from(element, {
    duration: 2,
    autoAlpha: 0,
    y: y,
    x: x,
    ease: "elastic.out(1,0.75)",
    scrollTrigger: {
      trigger: element,
      scrub: 1,
      markers: true
    }
  }, "+=0");
});

 

The only difference I can think of between local and live is that one is without SSL and live is with SSL, I am not sure if it has any bearing. Local is npm version 7 and live is npm version 8, again, not sure if it has any bearing.

 

Other than that, I cannot think of frontend related differences.

 

If it is working locally and on codepen, why is gsap failing to animate 'from' to 'to' on live?

 

[GreenSock]

Is the version of GSAP identical in both setups? There was a regression in 3.9.1 related to a particular scenario with .fromTo()/.from() tweens which has been resolved in the next release already. I wonder if your live site is loading 3.9.1 and the CodePen version is loading an older one? 

 

In order to effectively troubleshoot, we really need a way to reproduce the problem in an editable environment. 

[Saleem Beg]

@GreenSock / Jack,

 

That was it. The local was installing 3.8.0 while the live was loading 3.9.1.

So I removed the preceding ^ in the version like so:

"gsap": "npm:@gsap/shockingly@3.8.0",

And this seems to have fixed the issue.

Thanks so much for your help!