Dialog animations - overlay outliving the dialog results in dialog's end-animation styles resetting

[arackaf]

Describe the bug

If a dialog's overlay's hide animation takes longer than the dialog's hide animation, the dialog's styles revert once the dialog's animation has finished, but while the overlay is still going. This means the dialog re-appears.

setDefaultAnimation("dialog.hide", {
  keyframes: [
    { opacity: 1, transform: "translate3d(0px, 0px, 0px)" },
    { opacity: 0, transform: "translate3d(0px, 20px, 0px)" }
  ],
  options: { duration: 200, easing: "ease-in" }
});
setDefaultAnimation("dialog.overlay.hide", {
  keyframes: [{ opacity: 1 }, { opacity: 0 }],
  options: { duration: 1500, easing: "cubic-bezier(0.190, 1.000, 0.220, 1.000)" }
});

To Reproduce

Steps to reproduce the behavior:

No repl - see code above. I assume the hide animations need something like

animation-fill-mode: forwards

Demo

n/a but I could build one if you really need it

Screenshots

n/a

Browser / OS

• OS: Mac
• Browser: Chrome
• Browser version: 104

Additional information

n/a

[claviska]

Repro'd and confirmed. I'll get a fix for this soon...thanks for the report!

[claviska]

Fixed by applying fill: 'forwards' to the internal animateTo() function. This is a better default than none since most of the time we'll want the component to remain as it was animated.

This fix will be available soon in 2.0.0-beta.82.

[claviska]

While the patch in 326816e fixed the issue for dialogs/drawers, it caused issues with tree/tree item where the focus ring was clipped due to the leftover animation styles. 🙈

I reverted that fix and, instead, improved the animation logic in both dialog and drawer to account for different durations. Both components now work as expected, although I would caution users that using a longer animation for overlays may confuse users since it blocks the UI.

This fix will be available soon in 2.0.0-beta.82.

[arackaf]

Awesome man - thanks so much!