iDad5

Strange behavior number 1 is: I have two ways of creating my ScrollTrigger: A: const fullHeight = numberOfPanels * heightOfWindow; gsap.set(container, {height: fullHeight}); var trigger = ScrollTrigger.create({ trigger: container, start: 'top top', end: 'bottom bottom', pinSpacing: false, ... } B: const fullHeight = numberOfPanels * heightOfWindow; var trigger = ScrollTrigger.create({ trigger: container, start: 'top top', end: fullHeight, pinSpacing: true, ... } Both versions act absolutely the same everywhere but in iOS. In iOS Version A scrolls to the last panel, never saps to it though, and snaps back to the one before last. Version B sticks to the end as expected. (At least it did with my local version, with the codePen to follow, it sticks, but reports an endless loop of toggle and leave calls.) Version A: https://codepen.io/iDad5/pen/KKBJKrE Version B: https://codepen.io/iDad5/pen/yLqwXBp I know, they are not super simple yet, but when I created a version even simpler, even Version A worked. I would very much appreciate if someone could check out if the described behavior with the codePens can be reproduced on other devices than the two iPhones and two iPads I tested on.

BUMMER! ? The system I thought I found would work now broke the solution that @GreenSock provided to my initial problem. So, I have to build a minimal demo or actually two—the thing is, that I would need to incorporate the ScrollTrigger beta 3.11.5 in my pens. Is there a way to do so?

That’s hard for me to judge. In my opinion the two approaches I described above should behave the exact same way - and to 99% they do. If I had done the programming I would guess I had to look into it. But I‘m not half as good as any of you, and it’s likely that there is a perfect reason for why one works and the other does not. The problem of the wrong label reporting I‘d consider an issue that could be worth looking into, but I don’t know how to consistently reproduce it, and it seems not a big issue. I will make two very simple demos for the two approaches as soon as I have fixed my live issues. And if the different behavior is reproduceable in a simple demo, I’ll post them here. In case the issue is only occurring in my more complex setup I will let you know. Ok?

So to salvage things for the moment, I resolved not to use ScrollTrigger on mobile but to go with Observer and move the timeline accordingly. After all, that would 'more correct' as nothing really scrolls. But I still couldn't stop wondering why the solution with the body/fixed scroll was not reaching the end. So, before starting to rework things as described, I did some more testing concerning the end value of ScrollTrigger. Changing from my method of generating the scrollable distance by multiplying my triggers' height and using: pinSpacing: false, end: 'bottom bottom' to not multiplying my triggers' height and using: pinSpacing: true, end: multipliedHeightAsNumber solved the problem (of not reaching the end on mobile) to my utter astonishment. As a side effect, I do get more 'wrong label reporting' now again—but I'm used to handling those. @GreenSock I know that's a lot of descriptive text again, sorry. If you deem the issue worth investigating deeper, I will build a minimal demo or two. But I guess you have better things to do, relaxing and recovering your health probably the most important for you and all of us that depend on your fantastic work.

Thank you! You are a hero, and I'm a big fan of yours. You and your team are an inspiration and a great example of how things could and should be. Alas, as much as I like to have fun experimenting and making things generate unique experiences, the whole scroll 'abuse' thing somehow felt wrong to me from a usability and accessibility perspective early on. Not your fault at all, you just technically made work things a lot better than others doing it worse. Probably I will stop (ab)using scrolling for the time being, I'll sleep over it.

I forgot to mention, that updated the two codePens to work. But as codePens are not very good for mobile testing in my experience, I also made two local versions: Body: https://dev.thewebworks.de/playground/panels/ Window: https://dev.thewebworks.de/playground/panels/1.html And now, I didn't use ScrollTrigger.normalizeScroll() I have tried it quickly on the local versions, and it seems to break the windowed version completely. The Body version jitters a lot now when snapping, but sometime makes the last panel stay—not always, though. I will dig deeper after some fresh air... Thank you very much for all your support!

I have to admit that I doubted that statement at first, as there is no other Element that can move/scroll in the page. Furthermore, when I change the height of the pin-spacer that is the only thing that influences the scrollbar. But when I log the scroll position of the pin-spacer or look at its scrollTop in the dev-tool's properties, it is not moving. Actually, the documentElement is the one that scrolls… — because of its height set to 100%. But I think this more of an academic question. What I did is making two simple versions of the project with the learnings of this thread. I cleaned up the body version a bit and made a window version with 'translate' that also works. I did this because of my trouble with iOS/iPadOs (I haven't tested on Android yet, but I guess it might be differently trick but tricky nonetheless.) And I'm going CRAZY now. Both versions are basically unusable on the iPhone and on the iPad. The Body version runs somewhat ok, especially regarding the fact that the images I use are enormously large (on purpose for now). But ScrollTrigger refuses to show the last panel. It always jumps back to the third one. When logging, it just never reaches the last snapToggle and onLeave event it simply snaps back to the 3rd panel. The expected and usual snap event sequence for one scroll down is: snap toggle (without interaction at the start) snap complete (reaching the second panel) snap complete (3rd panel) snap toggle (last panel) (then on leave is fired) and snap complete for the last panel. The last three are never fired in iOS. Instead after reaching (visually) the last panel it snaps back to the third panel, firing its snap complete event. Here is no way I can make the last panel stick, even if I only scroll very cautiously a millimeter to the top with panel 3 snapped in the scroll to panel 4 starts but at the end returns to panel 3. The Window version with transform is running far worse, trembling a lot. It does snap to the last panel, but not playing the animation scrolling away the 3rd panel and just snapping in the last. Also in iOS even more 'wrong label reporting'* is going on than with the transform version, while in the body version this seems to work good now. (I set overscroll-behavior to none for the HTML and the body (and as a test for all elements) but that does not solve the issue.) I feel like jumping from the balcony right now, as I don't see any feasible solution to make it work on mobile. It used to work, even though it never was 'perfect', but now it is simply unusable. I am very certain that it is Apple that f..ed up everything and likely Android to with the whole “expanding interface” c...p and other non-standard 'optimizations' in scroll-behavior. I spent days now trying to save my project on mobile, but I might have to resort to a non ScrollTrigger version for mobile. * (wrong label reporting) I need a way to know when which panel has snapped into. The way to get that information (as suggested, if I recall correctly, by Jack himself) is to check for the animations current label property onToggle and onSnapComplete. This use to be incorrect a lot in the past, but seems to work correctly now with the fixed/body version of ScrollTriggger. It still reports wrong sometimes on desktop with the transform/window version but rarely—on iOS it still happens a lot, though.

As the example actually builds a circle which by its very nature is a loop and endless too, you should not need another loop helper. If you simply check on dragEnd if the rotation of the circle has to be corrected to the nearest snap rotation, and tween the rotation accordingly, that should do. As far as I understand your intentions. If you have a much larger number of cards than can be sensibly fitted into a circle of that sort, you have to replace the one 'behind' you with each nth of the rotation.

Thank you. The body tag was not the problem (mine was simply removed, as was the leftover closing HTML tag). I had the exact same behavior in my local test environment. My construction of the ScrollTrigger is somewhat unusual, I guess, and maybe I should have done it another way from the beginning—though I'm uncertain if I could have. The thing is that it works just fine with the body as the scroller. And completely restructuring and rewriting the whole thing would be hard, and I hope unnecessary. I try to describe how it works as I understand it by now: I give the container a height of n-times that of the screen/panel (n being the number of panels) as there's nothing to scroll with the panels all positioned absolutely on top. ScrollTrigger wraps the container in the pin-spacer of the same height. And sets the container to positioned 'fixed'. The pin-spacer is the only element that actually scrolls, as all its contents are fixed. ScrollTrigger moves along, scrubbing the timeline. Works fine on the body With another element than the body as a scroller ScrollTrigger moves the pined element exactly the same distance down with transform translate, that the pin-spacer is scrolled up. As my container is n-times higher than it's content, it scrolls out of view, or to be more precise, it scrolls its empty bottom into view. As it is not fixed this time. When trying to use fixed either in with ScrollTrigger's pin type or by setting the containers style to position fixed, there is noting to scroll, for the browser it seems, even though the pin-spacer is created and should be scrollable. My guess is that by fixing the container, it 'covers' everything. So, pin type 'fixed' on another element than the body will likely only work if the pinned element is not full-size. I will make some tests with pinSpacing true and a numeric value as the end point for ScrollTrigger, but I'm not sure if that will break other tings in my project, and my gut tells me that position fixed should perform better than translate. I might have to deal with the mobile issues in another, likely more complex, way. Therefore, I repeat my side quest question with more urgency: Does anyone know about a way to detect if the mobile address bar overlays the top or the bottom part of a page?

Thank you very much @Cassie aside from starting without a picture, scrollbars behaving somewhat unruly it looks very promising. Also, the scroll path seems a lot longer than I would like it to be, but that should be solvable.

I guess I found a hint here: But when I use pinType fixed, nothing will scroll, but I will investigate further.

Ok, this is a (kind of) follow-up to the last topic that @GreenSock saved my life with. Background: As with this kind of page, the annoying behavior of most mobile browsers to hide the address bar when the body scrolls and thereby triggering (unpredictable) resize events. Which I in turn have to ignore, but that leaves me with ugly leftover space. I can fill this for the price of recalculating everything, but then I have to watch out for when the address bar returns… I could work with that, but as the behavior is inconsistent on devices, it seems not worth the effort. (Side quest: does anyone know about a way to detect if the address bar overlays the top or the bottom part of a page?) To avoid body scroll at all, I try to pack my page into a container “window”—and I get unexpected results. Core Topic As you can see in the two CodePens when I do my stuff with the body as scroll target The pin spacer wraps around the container and the container stays in the pin-spacer while scrolling. Therefore, scrolling stops at the expected moment. As you can see in the second pen, if I do (at least in my simple mind) the exact same thing one level down, something different happens: The pin-spacer still wraps around the container but now when I scroll the pin-spacer is scrolled like before, but also the container is translated out of the pin-spacer by the same amount. Thereby doubling scroll speed (with which I could live) but also effectively doubling the height of the window's content, allowing to scroll the wannabe pined content out of the window. I guess I'm simply missing something obvious and will be pointed in the right direction easily. I did reduce my code from last time a lot, but I do know that it still might be deemed a bit more complex than absolutely necessary—I apologize if that's the case. And in case the issue is against my expectations hard to understand and exotic to love, I will try to boil it down some more. The top one is the try with the window, the bottom one is the original version in the body https://codepen.io/iDad5/pen/zYLeYev

@GreenSock: Thank you so very much, Jack! I somehow feel bad that you did this while you are ill, but I won't question your decision. The new version works exactly as intended. Thank you for the explanation, I wasn't surprised to see the onRefresh() after the creation of a ScrollTrigger instance—I would have been if I hadn't seen it, I guess. My musings were meant to help those overwhelmed by all those logs, but it seems they did not. It is, and I was aware that I'wasn't doing a very good job with it. I did start out with a real minimal demo at first, but after several tries and 2 plus hours of trying I couldn't reproduce the issue. As I had the previously working very complex example, I finally went on reducing 1200 Lines of code to 400, where I hoped that It would be easy to ignore half of it. I will try to do better next time. Again thank you and @Cassie and @Rodrigo too for being very helpful and patient as always! I wish you fast and full recovery, Jack and send you a big package of thankful thoughts.

Oh sorry, just now realized that OP accepted your answer @Rodrigo, please ignore my musings.

As far as my sore eyes can tell, the icon is not where OP wants it to be height wise. One would have to wait until the speech-bubble is actually rendered to measure its target Y. Which in turn would probably necessitate a resize/reflow listener if the font size or screen-size changes after the fact. Doable, but not a lot of fun to test and debug for an effect hardly anyone will recognize or value, I'd guess. Why not place the icon with flex or grid and instead of moving it, hide it and show it anew? (Something like sucking it in and pushing it out could work…) or maybe use the Flip-Plugin with the CSS layout I suggest?

That I would rule out with some certainty, as the original version was an extensive pain in the behind, and once it worked, we tested it to the moon and back. I think it more likely that the extension and optimization of ScrollTrigger's (responsive) features had this unlikely side effect with my unlikely code.

Actually, I'm rather certain that it has nothing to do with the initial delay of 300ms. (As far as certainty goes for a mere mortal). Nothing happens before those 300 (Spartans) are over. What happens then might be the dance of death. I call the ScrollTrigger to go kill itself and next line my panels to recalculate themselves. Those calculations do involve waiting out several animationFrameRequests, as I need to make sure the elements I have to measure and analyze are in the position I need them to be, having been transparent, scaled and cropped before. ScrollTrigger's “default kill” however wants to rewind its animations before it leaves the stage and therefore (very likely) will also make sure that the necessary animation Frames have passed by, not to leave everything in a mess. (I got the idea through the stack traces of onRfresh, where delayedResize calls handleResize that calls kill and then a variable number of animationFrameRequests happen before the updates.) I am convinced that ScrollTrigger.kill uses a very sophisticated system to make sure it does its job of reversing the animations perfect. But my calculations that are intensive (albeit not too time-consuming overall) likely hold the actual “clean-up before I die” execution back or trigger said race condition. Even my dummy version in the first demo did the job “reliable” it seems. ScrollTrigger.kill(false) could/should be the solution, but there (I guess) might be the rare bug that escaped Jack and all you demigods, as it seems to do no proper clean-up. of the pin-spacer at least. But all of that is just idle speculation, and not worth bothering anyone but me. Should have found a better solution in the first place, or told the client, that their wishes are BS...

That is what I feared. Please let him know—if somehow possible and sensible—that we all need him to stay in bed and get well. Work be damned, people matter. I did remove the crucial part of calling the panels to do their calculations—and everything works just dandy. (Insert some swear-words here—or don't) except it does not, when resizing twice or thrice… My wild guess would be, that somehow completely killing off the magic thing that ScrollTrigger is working quite well when nothing else is going on. But when a lot of other stuff is “going on”, listeners will be left behind to haunt me. Probably I can find a way to do the calculations in a worker thread and not wait for them to finish before recreating, … If I sound lost here it is because I am, and the trouble in this case is, that debugging this system is no fun under easy circumstances. I will give it some thought and a try as soon as I can afford it. https://codepen.io/iDad5/pen/PoBydmo I guess that leave us mortals where we have always been… Thank you so much for your help!

Thank you so much @Cassie, but that is a bit beside the point. I do understand how tedious it can be to read all my palaver—but the thing is not so much the simple demon looking for mistakes, (I do make them all the time with passion…) In this case, it seems to boil down to the point of ScrollTrigger kill(). I have (or at least had—in my simple mind) a very convincing reason to kill and recreate my ScrollTrigger. And it use to work. Now I can either keep the default kill() which, leaves a refresh “hanging around” that disturbs the system, or if try kill with (false) which seems not to do a proper clean-up as it leaves me with a doubled pin-spacer and in the wake of it—an unpredictable mess. Your code, which is much cleaner and cleverer than mine, simply does not kill and recreate the ScrollTrigger, so your effort isn't helping to pin down the issue, As I stated clumsily in my other posts, I'm uncertain if there was or at least is now a much better way to solve my problems, but a) I wanted to help to track down a possible breaking issue and b) hoped to avoid opening the much more complex box of worms that the actual code is. I can simplify my demo-code some more, but the code itself will simply look silly, as there is no trace of the need for killing and recreating the ScrollTrigger left anywhere…. As good as the pure (CodePen) demo way of tackling issues mostly is, I feel it has limitations in some cases. Like the one at hand.

Here we go. The demo is not truly minimal, but I do hope it helps. Experimenting with kill(false) in the end got me nowhere, it just got more buggy all around. Still, I think that kill somehow is to blame for my troubles. I've added a lot of consle.log and traces to everything the ScrollTrigger does. (You need to use the dev-tools, the CodePen console won't do—no trace there, for example.) Especially the onRefresh log ? is what bothers me. In line 108 (createScrolltrigger method) I supposedly configure autoRefresh to only run at DOMContentLoaded but it runs with a resize (twice)—in the trace stack it seems however that it is triggered by kill()—is this possible? (I do call kill() after a resize) https://codepen.io/iDad5/pen/LYBgVON You can also test a plain version at: https://dev.thewebworks.de/playground/panels/ To reproduce: scroll to the second or third panel and resize the window. With a short delay, everything is reset and reordered, and with 'reInstateScrollTrigger' the Panel that was on display before the resize is scrolled into view. (Line 98) That works as intended (some entering, starting and updating is going on, but no harm done there). But then a refresh sets in and runs everything to rock-bottom. The script is still rather complex, but most of the functions should be self-explanatory and don't really play a part in my troubles. I left some of it in, to give a glimpse of why I chose to kill and rebuild the ScrollTrigger I'm not 100% sure if with the new version, I could do it another way. I do need to 'collapse' everything on resize though to do those brightness calculations and after those are done, I want to scroll back to the previously shown panel. With a change in window height, the scroll-position needs to be recalculated thus.

While preparing the demo, I found some hints that could point to the root of the problem: When I killed the ScrollTrigger, I did it with the defaults. That makes the ScrollTrigger obviously trying to revert things back, and likely might interfere with what my script tries to do. In the end it shouldn't matter much, as I do reset everything anyhow and set up things from the start once again. Interestingly though, when I use kill(false) I do get less interference, but the “pinspacer” is not cleared, and I get another one when recreating the ScrollTrigger. Oddly enough, though, I never get more than 2. I hoe that I will have the demo online soon.

Also I'm not 100% sure what triggers the refresh, as the ScrollTrigger is minted newly after the resize (I react only to the resize after a delay of 3oo ms) the whole refresh is strange—the three animation frames were traced out somewhere, and thus I guessed that it must have to do with the resize somehow… Will investigate and demo…

actually I'm currently using the 3.11.5 beta, and used 3.11.4 before for sure. But demo it will be - asap.

Yes, that is a very valid point. I guess it depends very much on your actual use case. In my experience it is mostly us designers/developers that scrub up and down the animation, to a lesser part your customers (being critical or happy)—but the actual target audience is going one way only if at all. Hopefully dutifully impressed, they want to go on to the intended target. The backward animation being less smooth might be an ok trade-off in real-life, especially when the animation might change (Updating one video vs an image sequence…) sometime in the future. It's a question of balance. Longer load times might cost you traffic, jerky backwards animation might be less impressive but likely users will blame it on their connection/device or device. Call me devious…

Hi Jack, So sorry to hear that you had to go through such hard times. I do understand and sympathize. I barely made it alive through the last months myself, for different but not altogether unrelated reasons, I suppose. The troubles with webpages working only near to perfection should pale in light of this; classical first world problems. I'm still challenged by your hijacking my body but probably you are the only living person I trust that you know so much better than me. I'll have to decide between taking the time to build a 'minimal' demo or reworking the thing from the ground up—which might be beneficial anyhow but even more unpredictable. I'll give it one more try as a 'dry run' before I decide and if you don't feel like considering it, it is it's just fine, I do know and value your dedication as you hopefully know! Is there a way to make ScrollTrigger not react to window resize. (The ScrollTrigger.config thing seems not to work.)? Essentially what I have is a newly minted ScrollTrigger, placed at the desired position right after creation with scroll(position) and everything seems dandy. Then a refresh is triggerd (I guess belatedly through 3 ticking animation frames, and I'll end up at the very bottom for some reason.) I tried to just set 'debugger' after scrollTrigger.scroll(position); this.createScrolltrigger(); console.log('actual scroll after scrollTrigger creation: ' + document.documentElement.scrollTop); // logs 0 as expected' this.scrollTrigger.scroll(targetWinScrollTop); console.log('actual scroll after scrollTrigger scroll(): ' + document.documentElement.scrollTop); // logs targetWinScrollTop's value debugger; // BUT: the scrollbar on the browser-window is fully on top, the panel shown is always the last one... // Probably the sudden stop happens before any page render, so that might not be of any use.. My script does nothing after that sequence. I have, however, added those lines to my ScrollTrigger creation: onEnter: self => { console.log('Entering scroll trigger at:' + self.scroll()); }, onUpdate: self => { console.log('updating: ' + self.scroll()); }, onRefresh: self => { console.log('? scroll trigger refresh: ' + self.scroll()); } and with my target scroll being 1680 I get the following output, when debugger is commented out: The last trace from my script: > actual scroll after scrollTrigger scroll(): 1680 // from then: > updating: 1680 > entering scroll trigger at:1680 > updating: 1680 > ? scroll trigger refresh: 5072 > updating 0 > ? scroll trigger refresh: 5072 Window position is by display and programmatically 5072 then and also the 'endScroll' event is fired once and proves the position (and the reached last label) programmatically.