ScrollTrigger Labels onSnapComplete

[iDad5]

Hi all,

 

I'm working on a page that basically consists of fullscreen panels that blend (and slightly move) in controlled by a scrollTrigger.
The content will be generated by a cms and there will be a least two different kinds of panels. (The difference will not really matter in regard to my question/problem it just might help explain my round about way of doing things.)

 

Basically I dynamically build a timeline that adds a label for each panel and a 'to' to blend/move in the label one after the other...

tl = gsap.timeline({
	scrollTrigger:{
		trigger: container,
		start: 'top',
		end: 'bottom',
		scrub: true,
		pin: true,
		snap: {
			snapTo: 'labels',
			},
		onSnapComplete: self => console.log(self.animation.currentLabel())
});
tl.addLabel('panel1');
tl.to(panel2, {y:0, autoAlpha:1});
tl.addLabel('panel2');
tl.to(panel3, {y:0, autoAlpha:1});
tl.addLabel('panel3');
...

the ''onSnapComplete: self => console.log(self.animation.currentLabel())" line I took from a suggestion from @GreenSock from this thread: 

 

and it kind of works.

 

As you might see in the codePen, the snapping works, but the labels that are reported are inconsistent.

 

When I manually fully scroll to the bottom no snapComplete is fired, and more often than not the label that is reported isn't consistent with the panel that is shown...

What am I doing wrong?

Thanks in advance.

 

Also: When I size the container (my trigger) to 300vh for 3 panels I can scroll into  nirvana, when the container is 200hv it works as expected - somhow I am struggling with the concept of that.

See the Pen ExvQmBM by mdrei (@mdrei) on CodePen

Edited November 4, 2021 by iDad5
I forgot

[GreenSock]

As to the first issue, it looks like that's due to the fact that the browser is lagging a bit on firing the "scroll" event that consequently updates the ScrollTrigger's and animation's progress, so in the next release I'll add a line of code to force that but for now you can simply call self.update() in your onSnapComplete (before you check the currentLabel()). Or you could just wait for a requestAnimationFrame if you prefer, but I think it's easier to just call self.update(). 

 

7 hours ago, iDad5 said:

Also: When I size the container (my trigger) to 300vh for 3 panels I can scroll into  nirvana, when the container is 200hv it works as expected - somehow I am struggling with the concept of that.

Yeah, that's just a CSS thing. You've got the panels set to position: absolute, thus they're taken out of the document flow and the #container has a height of 0! Then in your JS, you're forcing it to 100vh. When #container is in the normal flow of the document it's fine because the child elements are stretching the page out 300vh but then when your pinning kicks in and it removes the #container from the document flow, setting it to position: fixed, suddenly the page collapses. ScrollTrigger is doing what it's supposed to be doing in terms of setting the pin-container to be the height of the pinned element which you set to 100vh. 

 

Perhaps you could set its height to 300vh. I'm not really sure what effect you're going after, but hopefully the explanation helps you get what you need. 

[iDad5]

Thank you very much @GreenSock for you help, I implemented self.update() and made some tweaks to get it working smoothly. 

One problem I have is, that snapComplete seems not to fire when the system snaps back to the first (/top) panel. Is there something I'm doing wrong?

 

See the Pen rNzrqmV by mdrei (@mdrei) on CodePen

 

Setting the height to 300vh works, when setting pinSpacing to false.  I wanted to have a scroll distance of one page-height per panel. When I scroll slowly everything works as expected, but whenever I scroll down fast, the page height somehow seem to double and I scroll into the white abyss. When I scroll back,  the page shrinks back.
What can I do to correct this?

[GreenSock]

9 hours ago, iDad5 said:

snapComplete seems not to fire when the system snaps back to the first (/top) panel

I can't replicate that issue. Are you sure? Can anyone else replicate that?

 

9 hours ago, iDad5 said:

Setting the height to 300vh works, when setting pinSpacing to false.  I wanted to have a scroll distance of one page-height per panel. When I scroll slowly everything works as expected, but whenever I scroll down fast, the page height somehow seem to double and I scroll into the white abyss. When I scroll back,  the page shrinks back.
What can I do to correct this?

This sounds like logic issues in your CSS related to what I already explained above. I don't have time to explore all that at the moment - we really try to keep these forums focused on GSAP-specific questions. One other idea, though, is just that the markers that ScrollTrigger is adding (because you set markers: true) is affecting the overall height of the scrollable page, beyond the 300vh, so try setting markers: false and see if that resolves things for you. Obviously those should be turned off when you deploy anyway. And it isn't a bug that markers affect the height - it has to be that way. 

[OSUblake]

2 hours ago, GreenSock said:

I can't replicate that issue. Are you sure? Can anyone else replicate that?

 

Works fine for me.

[iDad5]

Thank you both. The hint from @GreenSockregarding the markers saved me.
Regarding the other problem, ist seems to be related to my environment, that I sometimes have strange behaviour, I'm not totally sure about the how and why, but ist seems related to what I was describing in the other thread. 

 

Thanks for all your time and effort on my hopeless self. 

[iDad5]

Still some trouble to report here: 

While the label reporting in the codepen worked consistently with self.update() I had wrong reportings irregularly in my 'real' page but I thought that it might be my specific trouble and ignored it for the time being. WHen I added a fourth panel however the reporting of the two middle slides.labes became more or less consistently wrong - even on other machines. I extended the codePen example to 4 panels but it still worked as expected - which is odd, as my project has a very simple and similar structure, but with large images a lot more to paint. Different browsers on different machines has similar but not 100% consistent behaviour. 
I ended up with some lines of code to double check and correct erroneous reports but I thought I'd share my observation.

I also added a feature that auto-scrolls the page after a certain time of inactivity from the user, using the scrollTo plugin.  I scrolled to the target y and the scrollTrigger fired onSnapComplete only on Chrome Mac it didnt for the third panel.  I resorted to scrolling to 5 pixels less than precisely the position as a fix, that works ok for me, still wanted to share.

 

[GreenSock]

Hey, @iDad5 - can you please provide a minimal demo with specific instructions about how to reproduce the issue? We'd love to fix any bugs if they exist in ScrollTrigger, but I'm a bit lost about what you're describing here since it sounds like it all worked as expected in the CodePen minimal demo, right? 

[iDad5]

Hey, Jack - that is exactly my problem, it works well in my codePen Demo, that is an exact copy of what I do in my original minus decoration and some other stuff, that should likely have no influence.

I'm rather frustrated that I cannot provide better input. My guess was, that it might have to do with painting hires images and the timing of things. As You mentioned before, I could probably wait for 'requestAminationFrame' but I went down your suggested (easier) route with self.update() which seemed to help at first. I guess that another panel with another hires image plus some css transitions going on might cause the issues - I could try to build a version of my original that is as minimal as possible but complex enough to reproduce the issue, but I don't have the time right now...  (Also I guess that maybe CodePen might not be a good way of reproducing that kind of thing, so I would likely better provide it another way.)

 

I don't know if it helps, but I'm also 'auto-scrolling' the page in case the user does not interact with it for 5 sec. I use scrollTo plugin for it (I guess I mentioned it already) I do want to watch for a user-scroll to stop my auto-scroll.

As scrollTrigger and scrollTo do scrolling, I stopped watching for scroll events during scrollTo actions - that didn't work out as intended as scrollTrigger caused scroll events even after the complete of scrollTo. So I reactivated my watcher only after the scrollTrigger OnSnapComplete that works - mostly.

All in all my guess is that some browser optimizations might cause a delayed painting of stored 'stuff', and that might conflict with your brilliant optimizations under certain hard to predict and rare conditions....

[iDad5]

As I speculated before, what I experience might have something to do with my setup. I cannot pin it down clearly but it seems more and more to me it is related to the moving of browser windows between displays with different pixel density. (On windows one of my displays is a 4k 28" which i run on 125% and my macBook with a retina display on 2x  is connected to an older thunderbolt display with 1x, but I do most of my developing and testing on windows chrome...)