ScrollSmoother - Safari Issue related to ScrollSmoother (normalizeScroll)

[grizhlie]

Hi gang,

 

New to GSAP but loving it so far 😍. 

 

Wondering if anyone else found any issues whilst using the below. I am just WONDERING to be clear, I found a temporary "solution" as per below. 

 

1. ScrollSmoother (NEW)
2. Safari (Version 15.3 (17612.4.9.1.8))

 

For more context that shouldn't but might matter: I'm using SvelteKit, building a relatively 'simple' webpage. Hosted on Netlify. 

 

Issue/Bug:

 

When scrolling on this page I get jittery behaviour, for a flash I can see an image 'ghost' before everything corrects itself. 

 

This occurs only when I use my mouse-wheel. If I drag the scrollbar, all is well. 

 

When I set the below everything also seems to be fixed. Now I'm a complete noob with GSAP so perhaps I missed something obvious. Wondering if anyone has come across this bug? To my knowledge normalizeScroll improves behaviour (perhaps only suffering from this bug in Safari, perhaps this version of Safari, etc).

 

normalizeScroll: false //from true -> "Fixed" now!

The whole 'block' of code related to this:

 

const smoother = ScrollSmoother.create({
  smooth: 2,
  normalizeScroll: false, //Bug returns when this is set to true
  ignoreMobileResize: true,
  effects: true,
  preventDefault: true
});

Cheers

 

Griz

[GreenSock]

Welcome to the forums, @grizhlie! And thanks for being a Club GreenSock member. 🙌

 

I'm on Safari 15.4 and it's smooth as butter. Nice job on the site - it looks like somebody found the parallax features and data-speed="auto" in ScrollSmoother. 👏

 

The normalizeScroll feature is certainly not mandatory - honestly, it's more useful on mobile devices in my opinion but you definitely don't need to enable it if you don't like the effect. I haven't noticed any "ghosting" or anything like that, but maybe I'm missing something. I heard from the Apple team that in 15.4 they put a ton of effort into fixing various scroll-related issues. 

 

Also, why do you have preventDefault: true on your ScrollSmoother? That's not really an option. It shouldn't break anything, it's just pointless.

 

Have fun with the tools! And again, lovely work on the site. 

[grizhlie]

Thanks for the response and yeah this design started to come alive with GSAP. Initially I knew I'd like to animate 'stuff' but I didn't really think of exactly how. Then I think a random video of Cassie popped up in my feed and she was showing a demo of ScrollSmoother!! Rest is history.

 

I'm both happy and disappointed that you couldn't replicate my issue. No problem and thanks for explaining where it really helps - mobile. I'll do some tests and see where I stand after the dust settles.

 

As for preventDefault, honestly - no clue why I kept it in. I was testing GSAP in codepen to somewhat understand what's going on and I think I copied that part of the code and sort of forgot all about it 🥲.

 

Thanks again.

 

[Cassie]

Just dropping by to say beautiful site!

Also - sometimes juddering is as simple as too many/too large images. But yours seem to be sized relatively sanely.

[grizhlie]

@Cassie oh my, thank you  - work in progress as I learn GSAP and try not going overboard with animations but my client is rather happy about the progress so far! Thanks for this video with Jason, really opened my eyes to the possibilities. 

 

I'll play around with some demos after this project is finished to try understanding dos and donts! Thanks for the info on image sizing, will definitely throw that into the tests. 

 

 

[Cassie]

Jason is such a great host. Always a pleasure hanging out on his stream! Glad you found it useful.

[grizhlie]

Thanks a lot guys, the website is about 90% finished and GSAP made it feel magical (so far everyone loves it, especially my client).

 

One of my favourite coding experiences so far (Sveltekit + GSAP + Tailwind). I have to say that all 3 technologies scream simplicity and minimalism for the developer and the end results are amazing. Good to be a dev in 2022.

 

Not sure why I didn't jump on GSAP earlier 🥰

 

 

[Soh8]

@grizhlie Thanks, thanks to you I realized that "normalizeScroll: false" was messing up the scroll on mobile devices in one of my projects.

 

@GreenSock I think this should be either fixed or mentioned in the doc. Even on the https://greensock.com/scrollsmoother/ page, I have that issue on iPad where it's really buggy when I scroll. Somehow normalizeScroll seems to mess it up on touch devices. 

[Cassie]

If you could give us a bit more detail about the bugs that would be great @Soh8, we're in the process of fixing any issues that arise.

 

Normalize Scroll is our attempt to work around some existing IOS safari bugs - if you're not encountering any bugs in the first place then it's likely not necessary for your use case. In some cases, such as with pinning large images it vastly improves things on iPad. 

Just wondering if you'd taken a look at the page in the docs for it? We may need to link to it more clearly?

 

Quote

What's with the iOS browser bugs?

Here's just a sampling of the various unresolved bugs we encountered in Safari which was by far the most problematic browser (mostly on mobile): 

See the Pen 087cef197dc35445a0951e8935c41503 by GreenSock (@GreenSock) on CodePen

 | 

See the Pen 3dd65ccec5a60f1d862c355d84d14562 by GreenSock (@GreenSock) on CodePen

 | 

See the Pen 16c435b12ef09c38125204818e7b45fc by GreenSock (@GreenSock) on CodePen

 | 

See the Pen c0402caac3044c3f5bb85022450b059b by GreenSock (@GreenSock) on CodePen

. Some were reported back in January 2018 and still haven't been fixed. We tried reaching out to the Safari team directly on many occasions, but they were unresponsive. If anyone knows a way to reach them, please let us know; we'd love to collaborate on workarounds. We sunk hundreds of hours into troubleshooting and normalizeScroll() represents our best crack at working around the various browser bugs and inconsistencies. We welcome suggestions.

https://greensock.com/docs/v3/Plugins/ScrollTrigger/static.normalizeScroll()

[Soh8]

@Cassie Indeed it might not be necessary for my case ! At first by using it, I thought it would do no harm and prevent eventual issues...

But I guess that if it was necessary, I would encounter the scroll issue anyway by using the normalizeScroll option anyway. 

To see what I mean exactly, I think the best way to understand the issue would be to get an ipad and visit your scrollsmoother page: https://greensock.com/scrollsmoother/. If you don't see any issue, then ignore my message, maybe it's just my ipad. 

- ipad pro 2021, issue in safari & chrome  

 

 

 

 

 

[Cassie]

I'll check it out thanks for flagging it!

 

[stijlmassi]

With this stack, this site: https://agireflexology.com/ remains very stuttery on iOS Safari. In fact, I notice that smoothscrolling often is terrible on iOS. 

[stijlmassi]

Even on official examples in the Smoothscroll documentation, it doesn't work properly on iOS Safari without major stuttering. 

[grizhlie]

1 hour ago, stijlmassi said:

With this stack, this site: https://agireflexology.com/ remains very stuttery on iOS Safari. In fact, I notice that smoothscrolling often is terrible on iOS. 

I honestly gave up for now with this issue. Why? Because on my safari it works perfectly. My partner's safari perfectly. My friend's stuttery. 

 

🤷‍♂️

 

I stopped using SmoothScroll in recent projects to avoid stuff like this. 

[stijlmassi]

 

4 minutes ago, grizhlie said:

I honestly gave up for now with this issue. Why? Because on my safari it works perfectly. My partner's safari perfectly. My friend's stuttery. 

 

🤷‍♂️

 

I stopped using SmoothScroll in recent projects to avoid stuff like this. 

 

It's really regretful because I love this library, and I understand that most of these issues are due to Apple being quirky, but for the price there should be no reason as to why Lenis Smoothscroll works properly on iOS and GSAP doesn't. When Lenis is free. 

[GreenSock]

Very sorry about that, @stijlmassi and @grizhlie, but Lenis is a completely different type of solution. Both ScrollSmoother and Lenis have pros and cons to their approaches. Our original goal was to leverage native scroll technology (no scrolljacking, just let the user drag the scrollbar wherever they want but have the content smoothly "catch up"). This means that EVERY way of scrolling gets smoothed (drag the scrollbar, press the arrow or spacebar keys, etc.) whereas I think Lenis is more about intercepting mouse wheel events, preventing them, and basically creating a tween of sorts that updates the scrollTop/scrollLeft value. But it won't smooth if you scroll in other ways, as mentioned earlier. And of course ScrollSmoother has a bunch of extra features like lag and speed effects, etc.

 

I'm not criticizing Lenis at all - if it suits your needs, fantastic. Use it. Works great with GSAP/ScrollTrigger. But the fundamental nature of HOW things get scrolled is completely and radically different in ScrollSmoother. It's simply not possible, as far as I know, to completely solve the issues you mentioned while at the same time smoothing all of those inputs across the board and avoid scrolljacking. In a future major release, we very well may opt for a totally different approach but for now it's not really feasible (as far as I know) to "fix" what you mentioned because Safari is just absolutely terrible with various scroll-related bugs. We've spent many hundreds of hours trying to come up with the silver bullet workaround and the response we got from the Safari team was basically "nope, it's impossible". 

 

We'll definitely continue to look for ways to improve things in the coming months. If anyone has specific suggestions, we're all ears. 

[grizhlie]

@GreenSock All good from my perspective! I also blamed Safari and I don't see how you could tame that beast. Just reading "many hundreds of hours" makes me shiver with pain. In some ways I think of safari as a sort of pain like explorer was. Nothing quite so exact of course, but still painful in some cases to work with, this being one of them I guess!

 

Only suggestion is a question: Do you have any future plans to make GSAP more modular than it is currently, hence reducing its size?

 

I'm only asking because I saw a video about motion one, which is essentially praised for the modular approach they took. More curious than anything, it seems like the only selling point of motion one to me so far. 

[stijlmassi]

3 hours ago, grizhlie said:

@GreenSock All good from my perspective! I also blamed Safari and I don't see how you could tame that beast. Just reading "many hundreds of hours" makes me shiver with pain. In some ways I think of safari as a sort of pain like explorer was. Nothing quite so exact of course, but still painful in some cases to work with, this being one of them I guess!

 

Only suggestion is a question: Do you have any future plans to make GSAP more modular than it is currently, hence reducing its size?

 

I'm only asking because I saw a video about motion one, which is essentially praised for the modular approach they took. More curious than anything, it seems like the only selling point of motion one to me so far. 

 

Can I ask you to try forcing GPU rendition instead of CPU, it seems to have cut down the jitteriness a lot for me on iOS.

[Rodrigo]

Hi @stijlmassi,

 

What you could try is to setup force3D to true using gsap.defaults():

gsap.defaults({
  force3D: true,
});

https://greensock.com/docs/v3/GSAP/gsap.defaults()

 

Also another option is use will-change: transform in the smoother content element in order to prevent jitteriness in your app.

 

Hopefully this helps.

Happy Tweening!

[GreenSock]

On 9/19/2023 at 2:50 AM, grizhlie said:

Do you have any future plans to make GSAP more modular than it is currently, hence reducing its size?

Great question. I've thought a LOT about this and on the surface it seems like a great idea, but consider the following: 

1. The more modular, the less cacheable and "packagable". Currently, the "gsap" core object is super capable and robust. It has things like gsap.to(), gsap.timeline(), gsap.utils.*, gsap.ticker, gsap.globalTimeline, eases, etc., etc. Everything is very reliable, consistent, and ever-present. Load one file, and BOOM, you've got a ton of power at your fingertips. GSAP has been standardized on almost every ad network on the planet so that its file size doesn't count against ad budgets. Just one CDN had over 13 BILLION requests for GSAP in a single month. If we busted everything apart into little modular pieces, that might be nice for build tools but it'd be terrible for CDNs and browser caching. Please read this article: 
2. There are lots of inter-dependencies in the core. For example, tweens get put onto a global timeline, so you can't effectively separate Tweens and Timelines. Various internal functionalities rely on some of the utility functions. Another example: gsap.matchMedia() is insanely powerful but it requires some very deep hooks into the core that affect a lot of little pieces, so it's just not feasible to pull that out into its own little modular chunk unless we degraded performance by adding a bunch of little optional hooks and callbacks elsewhere in the core to bolt in the logic in the rights spots. It just made a lot more sense to bundle that functionality in the core. Better performance, and overall less file size as a whole. 
3. Performance or file size can sometimes be improved by reusing internal variables and chunks. So if they're all busted apart into their own little independent modules and then you try to put them together, you may end up with a larger file size because of the redundancies. For example, a lot of the easing functions are dynamically built using some helper functions that piece them all together. If they were all separated out, they'd each be bigger independently. Merging them results in overall file size savings if you're using more than a couple of them. 
4. It'd require a BIG change to the API. Again, you couldn't just rely on gsap.to(), gsap.from(), gsap.timeline(), etc. - we'd have to create little independent exports like Tween, Timeline, etc. that you'd import which may work well for build tools but then what about people who load GSAP over a CDN? We could try to put the most common things into a "gsap" object, but again, the overall size would likely be larger for that and then it'd get more clunky API-wise because the code itself would look different if you're using a bundler/ES Modules vs doing a standard <script> load from a CDN (like Tween(...) instead of gsap.to(...)). Historically, we've put a huge priority on consistency and ease of use. It goes counter to that if ES Module code looks different than UMD code. A lot of people have invested time into learning GSAP over the years and feel comfortable with the API, so switching things up like this could be quite jarring. 
5. Developers often think of file size in a way that's not very helpful or accurate. They simplify it to "bigger is always worse", but forget about caching or runtime performance tradeoffs or code clarity/portability/compatibility. They're quick to sacrifice all that other stuff in order to gain an average of maybe 10ms extra up-front load time...ONCE in their entire app/site. Even if it means their runtime animations bog down in the browser or their code can't be used in various other contexts. It becomes all about the initial file size hit rather than more of a holistic approach that considers all those other factors. 
6. We've already taken a modular approach in terms of GSAP "plugins". The features we deemed critical, we put into the core and then we wrap less commonly used features in plugins. That keeps file size down.  

I know it's easy for other newer libraries to tout small file size as a benefit to try to appear "better" than GSAP. And I have nothing against any of the other libraries in particular - use them if you like, but beware of the tradeoffs because they'll rarely mention them and we try not to talk too much about them because we don't want to seem like we're insulting the hard work of other library authors. 

 

Another way of looking at it: would you rather spend an extra 8ms (or whatever tiny fraction of a second it'd take to load GSAP by your average user) once on the initial load for an entire site and get all the rich benefits of GSAP including all the functionality and runtime performance or sacrifice that for the difference in load time that virtually nobody would notice?

 

All that being said, we'll certainly be looking for ways to increase modularity and minimize file size in future releases. ✅

 

And again, it was an excellent question. Thanks for giving me a chance to blabber on about it a little bit. 

[grizhlie]

41 minutes ago, GreenSock said:

I know it's easy for other newer libraries to tout small file size as a benefit to try to appear "better" than GSAP. And I have nothing against any of the other libraries in particular - use them if you like, but beware of the tradeoffs because they'll rarely mention them and we try not to talk too much about them because we don't want to seem like we're insulting the hard work of other library authors. 

 

Nice response! 

 

I wholeheartedly agree to be honest. I was just curious about your thoughts/plans on the matter. I looked at the video of Motion One and quickly saw little point. I'd need to relearn another tool and the only benefit was, as you said, a few ms of gains? No clue why that's important. I didn't know about caching to be honest, so good job on explaining that bit. I'll check the article you shared, sounds like I'll learn something.

Overall I didn't think Motion One looked better than GSAP. I was actually underwhelmed when someone explained to me that the key FEATURE was the size and modularity. But as you said, to do some things i do in GSAP id need to import a ton of things. 

 

Currently I mostly use `{gsap, ScrollTrigger}` and that's mostly it. I mostly do simple animations as I dislike too much motion in any given thing, but GSAP is perfect for that.

 

https://www.seerstudio.co.uk & https://seerstudio.co.uk/service are the main pages of my recent website. GSAP made animating this stuff painless. 

 

 

Thanks for explaining your thoughts, always nice to have a seasoned developer share their thoughts on a topic. I'm mostly a frontend focused person so I lack exposure to this sort of stuff, I appreciate it. 

 

And you're welcome, we all need to 'blabber' about things that we've been pondering on for days/weeks/months!

Ciao  

[grizhlie]

56 minutes ago, GreenSock said:

Historically, we've put a huge priority on consistency and ease of use.

This was worth responding to on its own. Ease of use is key in my view.

 

I currently have a very 'elegant' (to me) stack. I use SvelteKit, Tailwind, GSAP. I then add Storyblok for a headless CMS. I have made a system with Storyblok/SvelteKit that I can use in every project, and guess what - it includes gsap hehe. EVERYTHING JUST FLOWS ❤️.

[grizhlie]

On 9/19/2023 at 12:07 PM, stijlmassi said:

 

Can I ask you to try forcing GPU rendition instead of CPU, it seems to have cut down the jitteriness a lot for me on iOS.

You can ask me anything, but how/where do i do this? iPhone settings somewhere? Safari settings? I looked but didn't find anything specifically named as you suggested above. 

[GreenSock]

Oh, that's lovely to hear, thanks @grizhlie. And nice job on the site. 👏

[stijlmassi]

On 9/21/2023 at 11:32 PM, grizhlie said:

You can ask me anything, but how/where do i do this? iPhone settings somewhere? Safari settings? I looked but didn't find anything specifically named as you suggested above. 

 

Since you're using Tailwind, Tailwind has a transform-gpu class. Put that on the elements you are transforming. Let me know how it goes.