Jump to content
GreenSock

iDad5

ScrollTrigger on iPad (and iOS) trembling when snap to labels

Go to solution Solved by OSUblake,

Recommended Posts

Sorry for not (yet) having a minimal demo, I hope that someone can point me in the right direction without, but I'm willing to build one if needs be.

Also as the my problem ist related to iOS (and iPad OS) I might have to make a video if my explanation doesn't suffice.

 

The situation: I have 6 Sections that fill the Body (minus fixed footer and header) the first is an group picture with transparent divs overlayed that scrollto (gsap.plugin) the related section of the person. Each section has a Timeline with a scrollTrigger with a label dead center. 

 

All of that works without a hitch on all desktop-browsers I tested it on. (Including Safari on the Mac.)

 

I also have a onSnapComplete callback that fires an independent animation with a minimal delay. Also working as expected. 

 

On the i-devices however the sections tremble for quite a while regardless from of method i reach them. (Normal scrollling or scrollTo.)

 

I have a delay and a duration for snapping, but playing with those didn't help. I tried force3D with false and true to no avail worked autoKill: false into the scrollTo - no dice...

(I testet on an iPad Pro 12,9 " 4th gen and a iPhone 12proMax, so hardware speed isn't the likely reason)

 

Here is the temporary linke to the page https://bit.ly/3jSenqy so you can see and compare if you would want to. 

 

 I do hope that the issue is something that came up before and you can point me in the right direction. Thanks!

Link to comment
Share on other sites

  • Solution

I would try to narrow the problem down further. Like get rid of those profile animations and see if it's just a snapping issue. I would also highly recommend not animating top, left, right, and bottom and use x, y, xPercent, and yPercent instead. I would also try without that filter animation.

 

Also, you can try using will-change in your css for elements that you are animating.

.foo {
  will-change: transform;
}

.bar {
  will-change: transform, filter;
}

 

 

 

  • Like 1
Link to comment
Share on other sites

Thank You @OSUblake I couldn't fathom that ist would be a performance issue with those devices, generally he are quite capable and often a lot faster then my years old MacBookPro...

 

will-change actually helped though...

There still is some kind of fringe behavior with the way scrolling on i-Devices work with the acceleration and deceleration and also it is toublesome that 100vh isn't reliable due to the way the address bar works (and calc() with -webkit-fill-available doesn't work) but I guess I can live with that  behavior for now.

 

https://stackoverflow.com/a/37113430/6078346 has bad news for me, or is there a workaround, as this might be a tricky problem in a lot of scrollTrigger use-cases...

Link to comment
Share on other sites

First: Thank You @OSUblake interesting article, still in the end I decided not to go down that road or any other 'solution' to this problem for several reasons, some of them I'll talk about further down.

 

For my own reference and hopefully for others that run into similar problems I'll try summarize my findings here and would be grateful for further insights:

 

I identified 3 main factors contributing to my problems:

  1. Performance problem with the blur filter
  2. Inconsistent handling and reporting of the viewport height - due to the hiding of the address-bar
  3. Scroll acceleration and deceleration on touch devices

Performance problems with the blur filter on very recent high powered devices like the 4.gen iPad pro and and the iPhone12 ProMax took me by surprise. And I'm still not sure if that filter itself has a performance problem, as i looked very fine. But OSUblake's excellent suggestion 'solved' it for me (even though the warning on MDN makes it feel a bit hacky). Still I wonder if the new M1 iPads have the same problem or even worse the new M1 macs? (But that brings me to the testing dilemma, I'll elaborate on that in the end of this lengthy post..) Also I suppose that the problem is not in and of itself the cause for my troubles but in combination with point number 3. 

 

Hiding of the address-bar is a pain in the  ...  by its' own rights. There are several ways to tackle it like the one linked in the article above (again thanks to OSUblake); determine the height with address-bar through body.height() and the one without it through 100vh and doing some guesswork; etc. But that guesswork is just that. I did not find a way to find find a consistent way to predict or retrieve the moment when the address-bar goes away. Not even for one device on one OS. It does not go away when scrolling programmatically - it does mostly when scrolled by touch, the behavior is inconsistent with the keyboard and touchpad and it seems it even to make a difference  if you recently disconnected the tablet from those input devices...

Also, the hiding-behavior through touch is different once you scrolled programmatically before scrolling through touch.

Older and or other browser and OS versions reportedly do have other behavior.

A total clusterf... (please excuse my French here) and seeing the beta of iOS 15 where the whole browser-chrome-affair goes in a totally different direction, I decided that in my case - I live with it.

But even if at some point there would be consistent behavior and/or reliable event(s) that gave us a theoretical chance to know when what is happening, I guess that reflowing/resizing the content while scrolling would be (logical) hell anyhow in most cases.

 

Scroll acceleration and deceleration - as mentioned above even on one device the behavior is hard to predict depending on the environment and the input devices. Also consistent testing is not really possible even with good muscle memory :-) 

The problem I perceive btw. is with snapping: On the desktop when I over-scroll (regardless of the method - too much acceleration or just plain dragging too far) over a 'snap' - it snaps back and rests. On the iPad very often it seems as if even after snapping there is 'residual scrolling speed' and it scrolls again after snapping (onSnapComplete is fired already) an id snaps back again, sometimes more than one time.
I wasn't happy with it but I felt in my case it does not hurt to bad, but I imagine that in some cases it can really be a problem. Has anyone found a solution 
for that, or am I mistaken that a problem exists there?

 

Side-note on device-testing in general:

Nowadays I work mainly for small and medium sized clients and there is hardly any budget reserves for device-testing. Still if the site has problems on the bosses/cousins more or less exotic devices it is expected from me to fix it...
I guess I'm not alone with that problem, and I do try to test and fix as best I can. I have several iPads and iPhones and some older android devices but testing, let alone debugging on those is not only time consuming but also often nearly impossible. Also from time to time I have to / ant to install a beta of iOS on my 'ready to use' -devices, which has it's own drawbacks, but also it's advantages. Keeping around a lot of current devices purely for testing not only is very expensive, it also feels like by the time you are trough with all the testing, optimizing and retesting for side effects, the site needs a redesign already ;-).

How do you all handle this, if I may ask, looking for inspiration or at leas some confirmation. :-)

 

Thanks for reading.

 

 

 

Link to comment
Share on other sites

26 minutes ago, iDad5 said:

But OSUblake's excellent suggestion 'solved' it for me (even though the warning on MDN makes it feel a bit hacky)

 

That warning is so people don't abuse it. If you put will-change on every element thinking it's going to improve performance, it could actually do the opposite because it's going to use too much memory. It's one of those things you have to use sparingly.

  • Like 2
Link to comment
Share on other sites

4 hours ago, iDad5 said:

How do you all handle this, if I may ask, looking for inspiration or at leas some confirmation. :-)


Broswerstack, a few devices to test on and an initial list of supported devices/browsers to set client expectations.

  • Like 3
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.
×