Fifteen4

No worries! Thanks so much (as usual) for sorting this out. I'll be firing up the repo in question over the next couple weeks, so I'll keep you posted!

Hey, friends! Has there been any movement on this one? I've been running into some issues with the helper function as well (albeit perhaps not the same issues as this thread) and would love to know if a reliable solution has been found! It seems as if strong tags, em tags, and a tags all force strange breaks, even if they're not close to the end of the line.

Hey @GreenSock Sorry but I totally lied about getting back to you when I said I would! Haha evidently I forgot about Thanksgiving. If you celebrate, I hope yours was a wonderful one. In trying these betas out, the results are the same. The severe issue is gone entirely, but the vibrations and slight unpinning during/after snap still remains. I think it's definitely safe to say this is a rendering bug specific to something about my device. Perhaps there's some underlying difference in how the browser renders things as a response to a touch vs. when the scroll position is programmatically manipulated (as with a snap). Interestingly, though, on said (problematic) device — the scrollbar seems to sometimes not show at all with the new betas (noticed with the new scrollTrigger by itself and with both scrollTrigger + scrollSmoother). I'm able to scroll normally in any event, but occasionally the page loads entirely without a scroll bar. It seems intermittent as far as I can tell, but is most easily replicable after clearing my cache and returning to the demo after some time. In any event, thank you so much for tracking down a remedy for this! I'm eager to see the next version address it. In my situation, though, I may re-work things to use native sticky positioning and just use the scroll trigger to scrub the timeline and not worry about pinning. Since, in practice, there's only one full-screen element like this on the page, it may be worth carving out the exception to handle it.

@GreenSock Haha a beta test!? For Greensock!? Oh — the pleasure is all mine. After playing around with it for a while — trying all of our tests we've discussed and covered — I have to say it's a similar story as with the cache-busting onStart callback you gave me earlier today — the severe issue is entirely absent. The vibration, however, remains, but to a seemingly more subdued extent and limited only to the top of the viewport. Adding back the will-change props (to the pinned element and the scroller content) doesn't seem to have any effect — but given that I'm trying all this in the same CodePen example I posted above, I wonder if CodePen's iFrame is responsible for this effect on Android. The apparent difference in behavior relative to scrolling direction is also now irrelevant — the vibration just remains at the top (right under CodePen's minimal UI) when attempting to scroll during or after a snap. Perhaps a truly isolated full page may be treated differently? I can try this again in an isolated sandbox (no CodePen iFrames) tomorrow, but regardless, this is a significant (huge) improvement. Thanks so much for the improvements already — and I'll update you tomorrow.

@GreenSock so interestingly, this addition prevents the severe issue from popping up entirely. I wasn't able to reproduce the large boxes or complete "unpinning" at all after adding it. What does that mean in the context of the snapping? There is still the slight vibration happening (absent with no snapping enabled), but there's not anything nearly as drastic as before. I'm still entirely confused, but thank you so much for the improvement!

@GreenSock thanks for getting back! I certainly will add that and report back!

@GreenSock hmm that makes sense in context here. The issue seems so intermittent and bizarre that a browser (or OS) rendering/event propagation bug wouldn't surprise me one bit. Let me try and test both of these cases for you: Scrolling WHILE Snap is in progress: - Upon timing my scroll to "interrupt" the snap while I can definitely see the scrollbar still moving (so before the ease would really start to slow things down), I'm able to recreate the issue somewhat reliably. - In doing this, the issue seems to vary between some slight "vibrations" (20px or so of white background flashing at the top/botttom) all the way to the severe phenomena like the large white space shown in the video. Both of these would flash right at the moment of touch, then subside after a split second. - One *very* interesting thing I noticed is that the severe phenomena seems to only crop up when I "interrupt" a snap by scrolling in the SAME direction the snap is working towards. In fact, I was able to (twice) seemingly break things entirely, meaning the element remained "unpinned" even AFTER the snap completed (I waited probably 10 seconds) — only re-pinning if I were to scroll again. In digging further, it seemed like interrupting a snap by scrolling in the OPPOSITE direction of where a snap was working towards would only yield the vibration, not the severe phenomena. - Regarding the above, It might be worth noting that my android is using the "natural" scroll interaction (inverted?) — meaning that the page scrolls UP when my finger moves DOWN. Since the severe phenomena seems to pop up only when interrupting a snap by scrolling in the same direction as the snap, could there be something with the delta in touch start/move/end in that case? I don't know if this is even at play here, but this certainly threw up a red flag for me. Scrolling AFTER the snap finishes - After taking your recommendation and waiting for the snap to completely finish, I wasn't able to replicate the severe phenomena at all — regardless of direction. - I was, however, able to still replicate the vibration phenomena. It's worth noting that this doesn't occur at all when snap is disabled — in either direction. Does this help?

That's most of it! It's definitely restricted only to android (for now) and only when snapping is enabled. The main issue (more so than the top/bottom "vibrating") is that the pinned element seems to come entirely "unpinned" for a brief moment when attempting to scroll very shortly *after* a snap finishes. In my video, the most notable example of this is when the big white block appears at the bottom (or rather when the pinned element is no longer pinned, thus revealing the white body background underneath) just as my scroll begins at around 7 seconds. At this time, you can even see the little circles pop up towards the middle — these are what my fingers are doing when the problem arises. Does that help? Having just tried this, it seems to have had very minimal (if any) effect, unfortunately :(. I added the will-change prop to varying combinations of the pinned element, the scrollSmoother containers, etc. just to cover all of my bases. Thanks so much for looking at this!

Greetings, friends! So let me start by saying I've been happily using GSAP for about 7 years now and have been absolutely thrilled with it! Seriously, you all are a bunch of geniuses — this thing just works. I've been churning through a bit of a head scratcher recently, though, so I've finally decided to come out of my lurker mode and ask a question! I was trying to nail down some weird jumpiness in pinning full-height ScrollTrigger (and ScrollSmoother) elements on mobile devices. I'd worked through all the usual issues with this (mobile viewport resizing, browser address bar nonsense, etc.) with almost complete success, but just couldn't get the element to sit still upon first touching to scroll. I noticed that the issue was most prominent when scrolling shortly after letting a snap finish its work, so I removed snapping (literally just commented out the config line) and sure enough — it was perfect again. So it begs the question — am I missing something with the snap functionality? Is this a known issue on some devices? It's gravy on desktop devices, but gets finicky on my android (the only mobile device I've tested so far). Have I lost my mind? Any ideas would be appreciated forever ❤️ Here's some info that could help: Device: Google Pixel 6 Pro OS: Android 13 Browser: Chrome for Android v 107.0.5304.105 It's best to look at the pen in full-screen mode. I've also taken a screen recording that demonstrates it. There's a slight jank visible on the very top and bottom most of the time, but the most striking occurrence of the issue happens around 7 seconds in. Thank you all! screen-20221118-211410_2.mp4