Creating an example for this topic, I found a bug of stopping animation of an interactive component when the overlay is open.
Expected result
If the animation of the interactive component is in progress, and the overlay is opened at this time, the animation of the interactive component should not stop.
Actual result
When the button shows a loading animation, an overlay appears on the frame, and the button animation stops until the overlay is closed.
Additional information
Prototype:
I created a dropdown that opens when clicking on a specific menu tab, the dropdown opening is prototyped as an overlay in the project structure. Everything works correctly, but displaying dropdown overlay stops my smart animate looped slider animation, which is placed below the menu. I’m really curious how can I fix it, or If is there an alternative way to do it with keeping the looped animation after opening the dropdown overlay.
Demo:
https://www.figma.com/proto/jCc96LAfmqXp59MXGfU2K5/Untitled?node-id=5%3A4&scaling=min-zoom&page-id=0%3A1&starting-point-node-id=5%3A4
How tu use Demo:
Project:
https://www.figma.com/file/jCc96LAfmqXp59MXGfU2K5/Untitled?node-id=5%3A4
Have you found a solution yet? I have some problem
Unfortunately not, still investigating possible solutions. I would be happy to figure out about it.
Same here. First Figma bug that appeared to me. Furthermore, the buttons that usually trigger the animations stop working (are not interactive anymore).
I just noticed this bug, on a background progress loader bar component. While it’s not looping, it does have multiple stages. When a dropdown menu overlay is triggered, it causes the current smart animate to complete and hold.
I’m trying to think of any reason why this might be a feature rather than a bug, but either way there should be a way to set an overlay to not interrupt any background nested animations.
Following up on this—in case anyone comes back to this topic. Figma Technical Quality team reports that this is expected behavior, because they have architected overlays as a separate frame stacked over the current frame. As it is, this causes any active smart animate in the base frame to complete, and then it resumes where it left off when the overlay is closed.
So not a bug, but a technical limitation of today’s implementation of Overlays.
The workaround would be to create an invisible absolutely positioned frame overlay within the base frame that is toggled on or off via boolean variable. This is obviously not that elegant because you can’t use native overlay prototyping, but you should be able to achieve look and function with some effort.
Enter your E-mail address. We'll send you an e-mail with instructions to reset your password.
