3.2.6 to 3.3.1 Loss in transitions #388
Comments
|
Hey zslabs. It'd really help us in figuring out the issue if we didn't have to pull the entire project and filter through all of the irrelevant parts. Can you try to create a more minimal demo of the issue, perhaps in a CodePen or CodeSandbox? |
|
@ZachSaucier Here's a smaller reproduction https://codepen.io/zslabs/pen/qBbOzVR If you take off the |
|
Thanks! That's very helpful. That's definitely a bug and we'll get it fixed ASAP. |
|
Curiously if I change the position parameter of the second tween to 0.02 it works. But even 0.019 doesn't work. |
|
This is one of the reasons we strongly recommend ALWAYS setting your transform-related values via GSAP instead of only in CSS. It's fine to also set the initial ones in CSS to avoid FOUC, but when you set them in GSAP too it ensures that the proper values are cached and there's no ambiguity in rotational values. The browser always reports computed transforms as matrix() or matrix3d() which are px-based, thus it's impossible to discern percentage-based values and also rotations become ambiguous (i.e. rotation of 0, 360, 720, etc. are all identical matrices). Here's a fork that shows how it resolves things by simply setting the transforms via GSAP: Let me explain what's going on... You've got an element nested inside another one that's display: none which causes the browser to mis-report the transforms. Try this in your demo: let el = document.querySelector(".offcanvas-panel");
console.log(window.getComputedStyle(el).transform); // none!There was a "bug" report (not really a bug) at #375 that we accommodated by changing the kind of check we were doing (instead of checking for a null offsetParent, we checked to see if the element was in the <body>) but in your example that still fails. Elements with position: flex always report a null offsetParent. I'll roll back that change in order to resolve the edge case here. You can test out a preview of the next release (with this fix) here: Better?
That's just because when you pad the beginning like that, by the time that second tween renders for the first time, the parent element has had its display set to "block", thus transforms get reported correctly by the browser. |
|
And by the way, thanks so much for the reduced test case in CodePen @zslabs ! I know that takes you some extra time but it really helps us address it promptly and it ensures we're crystal clear on what the issue is. |
|
@jackdoyle That preview release does indeed resolve that issue! I really appreciate the explanation and the suggestion to move these initial styles to GSAP. I'll definitely do that moving forward. Thanks both for helping with this! |
- NEW: ScrollTrigger accommodates pinning the same element multiple times! Just make sure you create the ScrollTriggers in the order they'll be pinned. See https://greensock.com/forums/topic/24429-scrolltrigger-pinning-element-both-top-and-bottom and https://greensock.com/forums/topic/24421-issues-with-multiple-pins-in-a-row/ - IMPROVED: if a pinned ScrollTrigger's animation affects the pin element's transform, it now gets factored in to the final positioning of that pin. - IMPROVED: if you set up a toggleClass on a ScrollTrigger that has once: true, it will no longer toggle that class back onLeave (it will only happen onEnter because that's more intuitive). - FIXED: if you kill() a ScrollTrigger when it's in the middle of scrubbing or snapping, it wouldn't kill the in-progress scrubbing or snapping. - FIXED: if a tween with a stagger is overwritten, the staggered (nested) tweens that haven't started yet may render for one tick when they're scheduled to start - FIXED: a zero-duration tween (a set()) at the very beginning of a timeline may not render correctly in certain circumstances. See https://greensock.com/forums/topic/24358-scrolltrigger-set/ - FIXED: regression in 3.3.0 could cause initial transform-related values not to be parsed correctly if an ancestor element had dispaly: none. See #388 (this reverts the change made for #375) - FIXED: the pre-"from" values in a fromTo() may not render when the parent timeline's playhead rewinds past the beginning of that tween. - FIXED: gsap.utils.wrapYoyo() would return NaN if the start and end values matched. See https://greensock.com/forums/topic/24403-wrapyoyo00x-nan/ - FIXED: if you defined a toggleClass on a ScrollTrigger and that class affected positioning, a refresh() could miscalculate positions because the class wasn't removed for the measurements. See https://greensock.com/forums/topic/24412-scrolltriggerrefresh-help/
👋 Hi all, as part of https://github.com/gremlin/chaoskit (demo site) components like OffCanvas and Modal are using a
xandyproperties as part of their timeline, respectively. When upgrading to3.3.1I noticed this transition is lost. I also tried usingxPercentandyPercentwithout any luck, but I may be misunderstanding the point of those properties.Reproduction
package.jsonupgrade GSAP to3.3.1yarn develop(this will install all deps and fire up a Storybook instance)Please let me know if I can provide anymore context. Thanks!
The text was updated successfully, but these errors were encountered: