CityLights

Tested the new onInterrupt callback using the Codepen below https://codepen.io/citylights/pen/LYbmJjL Works like a charm, thank you.

With that approach, I face difficulties on both desktop and mobile. On desktop: since it is not possible to attach event listeners to the scrollbars, only to their associated elements, pointermove events (following a pointerdown event) which happen somewhere on the element but outside of its scrollbar would be mistaken for scrollbar scrolling, unless I made some nasty assumptions about scrollbar width, which can vary from browser to browser. Makes for a very brittle solution. On mobile: a pointerdownevent followed by pointermove events does not necessarily indicate scrolling. If the events land on a child element with touch-action: none, no scrolling would occur.

And if the user interrupts the snap by scrolling using the scrollbar instead of the mouse wheel? Or if the user is on mobile? Which events do you advise listening to, to account for those cases?

No, I already know when a snap starts by providing a function as the snapTo property to snap. What I wish for is a callback for when a snap is cancelled/interrupted due to user input.

As explained by @GreenSock, detecting a snap interruption is not so trivial. Since a mechanism to determine a snap interruption already exists as part of the library internals, creating application code for the same purpose is simply needless suffering. Not only would it be redundant code, but also painstakingly hard to maintain as it must closely imitate the library internals. So for users who need to detect snap interruptions, the upside of being able to leverage the library internals via the "onSnapInterrupt" hook is immeasurable and saves a ton of technical debt. On the other hand, the downside for users not using the hook is negligible. They will only suffer the additional runtime cost of a conditional statement checking for the presence of the 'onSnapInterrupt' callback when a snap interruption happens (which depending on the snap duration, is not so common anyways). I can't see such logic being expensive in terms of extra file size either.

Similar to the "onInterrupt" option for gsap tweens, "onSnapInterrupt" is a callback that fires when snapping is interrupted/cancelled due to user action.

I had a hard time understanding your question. As advised in the forum guidelines it's always a good idea to create a reproducible demo on Codepen. If you need Nuxt to demonstrate the issue you can use CodeSandbox Checking process.client should not be necessary as long as your create your ScrollTriggers in the mounted hook. Also make sure to dispose of them by killing them in the beforeDestroyed hook to avoid any lingering instances.

Yep! No longer able to reproduce the described behavior. Exceptional work, thank you. For anyone who lands on this thread, the Codepen attached includes a version of GSAP (v3.6.0) which is ahead of the latest stable release distributed via npm (v3.5.1). This means that the behavior described is currently no longer reproducible on the Codepen but is if you load v3.5.1 via a package manager.

Reproduction steps: 1. Scroll down to section "THREE" 2. Scroll down in a controlled fashion until the top of the next section is just below the text "THREE" (screenshot below) 3. Stop scrolling to allow ScrollTrigger to start snapping back to section "THREE" 4. During the snapping try to abort the snapping by scrolling 4. Relinquishment of scroll is not immediate making the page feel unresponsive

Thanks for the simple scenario-specific solution which leverages the snapping sections. How would you go about this if there was no snapping behavior and the user could stop their scroll position at intermediate points between the sections?

Reproduction steps: 1. Open the official demo attached in a new window 2. Scroll to the orange section saying "TWO" 2. Resize the window a significant amount After the resize and refresh complete, ScrollTrigger will snap to a section different than the one prior to the resize. What's an elegant way to fix this?