[ScrollTrigger feature request: "onSnapInterrupt" callback]

Tested the new onInterrupt callback using the Codepen below

See the Pen LYbmJjL by citylights (@citylights) on CodePen

Works like a charm, thank you.

[ScrollTrigger feature request: "onSnapInterrupt" callback]

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.

[ScrollTrigger feature request: "onSnapInterrupt" callback]

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?

[ScrollTrigger feature request: "onSnapInterrupt" callback]

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.

[ScrollTrigger feature request: "onSnapInterrupt" callback]

As explained by @GreenSock, detecting a snap interruption is not so trivial.
 

On 12/22/2020 at 12:47 AM, GreenSock said:

The way ScrollTrigger senses when it must kill the snapping is by checking if the current scroll position is the one that was previously set (or the time before that) by the tween itself. We can't just listen for a "scroll" event or something because those would get dispatched by the snapping itself, and the scrolling may be triggered by various different things (mousewheel, user drags the scrollbar, use JavaScript, touch-scroll on a mobile device, etc.) 

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.

[ScrollTrigger feature request: "onSnapInterrupt" callback]

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

[Nuxt, Vuetify and GSAP ScrollTrigger - wrong start position]

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.

[ScrollTrigger: intermittent scroll locking during snapping]

12 hours ago, GreenSock said:

Does that work better for you? 

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.

[ScrollTrigger: intermittent scroll locking during snapping]

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

See the Pen VwKzEeZ by citylights (@citylights) on CodePen

[ScrollTrigger fullpage sections: section change on resize]

On 12/11/2020 at 2:33 PM, ZachSaucier said:

Hey CityLights and welcome to the GreenSock forums.

 

To fix this you'll need to record which section is snapped to each time that it snaps. Then on refresh you should set the scroll position to the value it needs to be to have that section at the top of the viewport.

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?

[ScrollTrigger fullpage sections: section change on resize]

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?

 

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