Jump to content
Search Community

ScrollSmoother freaking out on touchmove

Sascha Fincher test
Moderator Tag

Recommended Posts

Hi everyone,

 

I know there has been a lot of discussions lately about ScrollSmoother and iOS/Safari, but I still could not find a solution to my problem.

 

I only see this happening on  iOS 15.4.1 on Safari. 

To see this effect you need to run the pen in debug mode.

When you touch down on the screen and start scrolling (with your finger down) really fast beyond the top of the viewport (basically to the very top of the url bar), the whole content disappears and reappears only when releasing your finger.

 

On the page I am developing this effect is even worse with the menu bar jumping wildly  around, but you can see the effect in the pen as well, although I only included the bare minimum to reproduce the effect.

 

Edit: This behaviour goes away when I disable normalize scroll. However, I actually like what the flag offers. Thinking about disabling it based on device detection, but this is never a stable solution since I do not know which devices would have that problem. 

 

See the Pen JjMVXEB by HankJamesMoody (@HankJamesMoody) on CodePen

Link to comment
Share on other sites

Ok, tried it out now. Even in the simple codpen it does not make a difference.

 

One more observation: On iOS 15 you can choose in the Safari setting if you like to have single tabs (url bar on top) or a tab bar (url on bottom). The whole problem only appears to happen when the url bar is on top.

 

In both scenarios the browser is hiding the bar(s) after a bit of scroll, but it seems only to be a problem when the top and the bottom bar needs to be hidden.

 

Edited by Sascha Fincher
update on investigation
Link to comment
Share on other sites

On 4/22/2022 at 12:18 PM, Sascha Fincher said:

Hi everyone,

 

I know there has been a lot of discussions lately about ScrollSmoother and iOS/Safari, but I still could not find a solution to my problem.

 

I only see this happening on  iOS 15.4.1 on Safari. 

To see this effect you need to run the pen in debug mode.

When you touch down on the screen and start scrolling (with your finger down) really fast beyond the top of the viewport (basically to the very top of the url bar), the whole content disappears and reappears only when releasing your finger.

 

On the page I am developing this effect is even worse with the menu bar jumping wildly  around, but you can see the effect in the pen as well, although I only included the bare minimum to reproduce the effect.

 

Edit: This behaviour goes away when I disable normalize scroll. However, I actually like what the flag offers. Thinking about disabling it based on device detection, but this is never a stable solution since I do not know which devices would have that problem. 

 

same issue for me 👀

Link to comment
Share on other sites

  • 2 weeks later...

Quick update. I thought this issue was fixed by version 3.10.5, but apparently it was not.

I was investigating a bit further and as you know the whole problem occurs because of iOS showing and hiding the navigation/tool bar.
Now, by setting body to window.innerHeight and position: fixed, the bars on iOS will always show and not move. However, SmoothScroller does not scroll in this case. 

My understanding is that the smooth-content is being Y translated when scrolling, so why does a 100vh (or rather window.innerHeight) body with position:fixed prevent it from scrolling? 

smooth-content gets an inline-style of position: absolute and when I do a normal css transform it moves as expected. However, the matrix3d transform that is applied by ScrollSmoother does not update when scrolling. Is this behavior intended by design?

Link to comment
Share on other sites

Got a minimal demo, @Sascha Fincher? It sounds to me like your setup would prevent ScrollSmoother from working because the body isn't scrolling at all. 

 

Overview of how ScrollSmoother works: 

  • Sets the height of the <body> to the #smooth-content height so that it can use NATIVE scroll on the root element (critical for accessibility and some other reasons)
  • #scroll-wrapper gets set to position: fixed
  • Then ScrollSmoother just watches the <body> scrollbar position and when it changes, it animates the matrix3d() on the #smooth-content element accordingly.

So if you're messing with the <body> height so that it's matches the window.innerHeight, that won't natively scroll anymore, thus ScrollSmoother isn't triggered to translate the content. 

 

I very well may be misunderstanding your question and/or setup which is why a minimal demo always really helps. 

 

Also, we originally tinkered with using a position: absolute or position: fixed element and using that element's scrollbar position as the driver (instead of <body>), but not only did that cause accessibility problems, it also created stacking context issues, pointer/wheel event bubbling challenges, and a few other show-stoppers. 

Link to comment
Share on other sites

45 minutes ago, GreenSock said:

 

So if you're messing with the <body> height so that it's matches the window.innerHeight, that won't natively scroll anymore, thus ScrollSmoother isn't triggered to translate the content. 

 

 

Indeed I did mess with the body height and position, because I did not want the body to scroll (to prevent hiding the bars).  :)

You did  understand my question very well and I do understand now that what I thought could be a solution to the initial problem I posted in the beginning of this thread will not work. Let's forget about this then :)

 

In that case the problem in the first penis still valid: 

 

 

You can also see it in one of your pens: 

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

 

 

  • Like 1
Link to comment
Share on other sites

  • 2 weeks later...

@Sascha Fincher sorry for the delayed response - it was a very thorny issue to track down but I made some significant improvements that should resolve this issue. Would you please try the latest beta files and let me know if things look good now?  You'll probably need to clear your cache or put some cache-busting stuff on the end of the URLs:

Thanks!

Link to comment
Share on other sites

Thanks guys. Just tested it out briefly. It still happens, but not as often as before. It happens 100% when doing the very first touchmove after page load. After that it sometimes happens, but only when doing movements from the visible browser area into the bottom tool bar and back up to the url bar. This happens not on every occasion. Still trying to find a pattern for this behavior. 
I am currently on my phone only and will create a new test pen tomorrow to make sure there is absolutely no caching issue.

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...