Basilico

Thanks, you made my day. ?

It works! ? How can I get my hands on that release?

Hi! I've found this and I think it's a bug. When I use ScrollSmoother and I need to call ScrollTrigger.refresh() (due to ajax loading, dom changes, etc.) the page "sometimes" it scrolls. If you click on the buttons in the demo, you can see it. You need to lick more times, scroll the page and so on. It won't happen if the page is scrolled down to the end or at the top.

It's crystal clear now! I also believed that a forEach was a safe way for doing that and so I didn't investigate in that direction. I will remember it now. Thanks!

Yes! Thanks! Do you mind explain me the problem? I'm just very curious and the source code is not published yet.

While I was working on a project I did some test logging the ScrollTrigger.killAll internal loop and I found that the forEach loop simply stops earlier. Even avoiding the "ScrollSmoother" test and just killing every "t", the loops ends before the end. And I found it really strange! _triggers.forEach(function (t) { return t.vars.id !== "ScrollSmoother" && t.kill(); }); But if I get the triggers with getAll and then loop them, it works.

As the codepen shows, the Scrolltrigger.killAll method leaves some instances behind. This is not happening if I use a loop based on the getAll() like this one: ScrollTrigger.getAll(t => t.kill())

Thanks, you're right. Calling the method like that it stores a new value. This means that I have to call ScrollTrigger.clearScrollMemory('manual');at the beginning of my code to store the right value. Probably the documentation needs to explain this feature better, because in my project I didn't think I need to call that method but now I found I need it to save the value. Unless this sentence in the doc: is valid also for Barba.js page transitions. Do you suggest to call that method every page transition? Thanks.

Here's the demo: https://codepen.io/fnool/pen/gOKmJRR

Hi, Scrolltrigger version 3.11.3 (and probably older versions too) save the history.scrollRestoration value at the beginning and it seems it's not possibile to overwrite that value later: _scrollRestoration = _win.history.scrollRestoration || "auto"; Then the stored value is applied again every clearScrollMemory call: _isString(scrollRestoration) && (_win.history.scrollRestoration = _scrollRestoration = scrollRestoration); Even setting history.scrollRestoration to manual at the beginning of my script, due to Webpack bundle, the Scrolltrigger code is extecuted before mine. In my case I need to set the scrollRestoration to manual because I use Barba.js Is there a way to do it? Am I missing something?

Also, I did a test with stats.js that show the fps and I found that in Low Power mode it runs at 30 instead of 60. But probably the native scroll is still running at 60.

Yes, I'm using 3.11.3 and it's more laggy with normalizeScroll.

Based on my tests, the normalizeScroll is a problem with Low power mode and it makes it very laggy. I'm developing a project based on scrollTriggers and for the moment I'm going to avoid that feature because "normal" scrollTriggers are working fine. Obviously I'm not going to use ScrollSmoother on mobile too. Thanks for the great effort you put in this library. GSAP is so useful and well done that is a shame the Safari team keeps ignoring these bugs.

Well.. it depends. If the website is heavily based on scrolltrigger it looks like a broken thing. Anyway, probably the reason because the testing was so difficult to debug was due to the battery mode.

I tried the demo provided here: https://cdpn.io/pen/debug/poLyVKR on an iPhone 6s and I found that the problem happens only when the battery is in "Low power mode". Anyone else?