Jump to content
Search Community

Problems with ScrollSmoother (3.11.5 - beta) on touch screen devices

coolDev test
Moderator Tag

Go to solution Solved by GreenSock,

Recommended Posts

Hello! I took this codepen from demo page. Made a fork and played with the settings. I noticed that on devices with a touch screen (ios, android) there are friezes. This issue occurs when the normalizeScroll and smoothTouch options are enabled (at the same time).
The problem occurs in version 3.11.5 (beta). When using an earlier version of the scrollTrigger and scrollSmoother, there are no such problems.

Attached is a link to a screen recording video. The video shows how at some point, the site freezes.

See the Pen xxawwjx by lexa18 (@lexa18) on CodePen

Link to comment
Share on other sites

Can you please tell me if you managed to find this problem? Is it fixable.
I apologize for my persistence. I want to clarify my impatience. My team assigned me to study GSAP. And to figure out how well it works, and what functions we can implement in our projects. The company plans to use GSAP for client projects.
Thank you for your patience!

Link to comment
Share on other sites

Hey there! 3.11.5 is an unreleased work-in-progress beta version. 

We're currently working on ironing out any bugs and getting this release out. But we can't give you an exact date I'm afraid. 

I looked in your post history and I can see you've chosen to use it in order to get around an issue in 3.11.4. Depending on which features you're planning on using it may be a better idea to roll back to a previous stable version for now? Then you could update to 3.11.5 after it's released. Beta versions are always a little unpredictable I'm afraid.

Also worth noting that normalizeScroll is just an option that sometimes helps to get around specific IOS bugs, in other instances you may be better off without it. It's definitely not something we recommend using for everything.

If you remove it on this demo and view it outside of an iframe in debug mode, it behaves more optimally.

https://cdpn.io/pen/debug/zYJqGNN

You can read more here.
https://greensock.com/docs/v3/Plugins/ScrollTrigger/static.normalizeScroll()

Specifics aside - Sorry for the frustration. If there's a certain use case you're struggling to figure out let us know and we'll try and find you the best solution while you're waiting on the latest release.

In terms of using GSAP on client projects, over 11 million sites use GSAP, including all these award winning sites. The web platform is ever-changing, browser updates and new specs do introduce bugs and issues do arise, but we've been squashing bugs, creating new tools and helping people build exceptional sites for over a decade now. You're in safe hands!
 

  • Like 1
Link to comment
Share on other sites

Quote

If you remove it on this demo and view it outside of an iframe in debug mode, it behaves more optimally.

https://cdpn.io/pen/debug/zYJqGNN

Sorry, but your example does not match the given parameters. In my first post, I pointed out that the bug occurs when the option to normalizeScroll and smoothTouch  is enabled at the same time. In your example, for some reason you turned off normalizeScroll. Turn it on and you'll get the bug I'm talking about. 

Moreover, this bug is present in the current version 3.11.4

Link to comment
Share on other sites

Sorry about the frustration, @coolDev. We're definitely looking into this and it is a top priority. It may help if I give you a little back story...

 

There are a bunch of bugs in iOS Safari. Some have existed for over 4 years, unaddressed. They are what I'd consider major, glaring issues that make it absolutely impossible to synchronize scrolling effects. Apple has even admitted that it's impossible. We've filed several bugs with them. Only one has been addressed from what I remember. I have burned probably at least 500 hours personally just working on trying to find ways around the browser bugs.

 

Add to that the fact that most modern browsers handle scrolling on a completely different thread than the main JS thread (they're trying to optimize performance) which, again, means sacrificing synchronization. So, for example, you swipe your finger to scroll and the browser has already recorded basically a screenshot of the content in the browser and it just moves that accordingly (to scroll), repaints it in the new position (all on the separate scrolling thread) and then a few milliseconds later, it runs the main JS thread which is where all the logic happens for anything JS-driven (like ScrollTrigger). So at that point ScrollTrigger says "hey, this thing should render like this..." and then the browser paints again and things look the way they're supposed to look. But let's say you have something pinned and it's inside an element that has transforms applied - well you CANNOT use position: fixed to do pinning in that case (the CSS spec dictates that creates a new containing context so it moves with the container that has transforms) - the only option is to actually counter-position it with transforms to make it appear pinned. So if you scroll 50 pixels, for example, the scrolling thread would actually render that element 50px down (or up) and then the main JS thread would run and ScrollTrigger would correct the position by applying the proper transform. That causes a vibration (scrolling thread renders wrong, then main thread renders correct, back and forth). 

 

The only "solution" to this (that I'm aware of) is to actually disconnect the regular scrolling so that the browser is no longer handling it, but instead you actually do the scrolling on the JS thread itself. THAT is what ScrollTrigger.normalizeScroll() does. But it's not a silver bullet, as @Cassie indicated. For example, iOS Safari has several bugs that actually cause it to completely misreport the scroll position in touch events if you set the scroll position on the main thread. Maddening! So normalizeScroll() has to skip every other requestAnimationFrame tick in terms of setting the position. And to prevent it from looking like the frame rate dropped, we actually apply a transform to the entire container on every other tick, interpolating where it should be based on momentum. So if you open dev tools and watch, you'll see a transform gets applied and then removed, applied, removed (only on iOS). 

 

I'm just giving you a little back story about why this is so incredibly complex and frustrating. I know that when you report an issue, you'd like it to be resolved immediately - I just want you to understand that we're sinking a ton of effort into solving these complexities so that you don't have to worry about them but sometimes it's a moving target, like when browsers release updates that have new bugs or change behavior, etc. 

 

Our goal with GSAP is to shield you from a ton of the browser quirks, bugs, incompatibilities, etc. so you can just focus on the fun stuff. 

 

ScrollTrigger.normalizeScroll() definitely helps a lot in a bunch of circumstances, but it's not a silver bullet and I'd still consider it somewhat experimental. It can solve the vibration that happens on iOS (big improvement) but it can be more demanding on the processor due to the logic it has to employ.

 

So rest assured we're looking into what you reported here and I'll get back to you once I've got a better idea of what's going on. I'm having a difficult time consistently reproducing it right now. If you've got any clues as to how to make it always happen (a sequence of steps), let me know. 

 

Thanks for your patience!

  • Like 3
  • Thanks 1
Link to comment
Share on other sites

Jack, thanks a lot for the comprehensive answer. You spent a lot of time on this explanation, I really appreciate it.
No frustration, gsap - beautiful. I'm just trying to understand all aspects of using gsap. I'm afraid to let my team down. Once again thanks!

  • Like 3
Link to comment
Share on other sites

  • Solution

Would you mind kicking the tires of the latest beta and letting me know if you're able to break it? 

(You'll likely need to clear your cache)

 

Here's a fork with those files in place: 

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

 

Debug mode (no iframe): 

https://cdpn.io/pen/debug/jOvrWzp

  • Like 2
  • Thanks 1
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...