Thanks, I was able to take a look. The root cause of what you’re seeing is a combination of the fact that flexible re-layouts happen when the window/viewport size changes and that changing the width of an group element isn’t a “flexible” resize. Here’s the breakdown:
- Your group (and image) has flexible layout on it
- The animation then makes the group width to -5000 pixels
- When resizing the window, the image will now look at this new group size in context of flexible layout and grow to match based on its size and rules
- When restoring the width, there’s nothing that triggers the re-layout so it stays this large size
I need to think further if this is a fixable issue from Hype’s end or if it is just a limitation of the current system. I’m pretty sure there was a reason we didn’t have a group’s resize trigger a re-layout of its components at one point, but with more flexible layout options we’ve added there might be new reasons that this could change.
It isn’t a great solution, but you could add onto the timeline actions a call to
hypeDocument.relayoutIfNecessary() and that will at least fix it up when the animation is done.
Layouts are conceptually different scenes. If you need behavior to preserve animation state, you can put elements in a Persistent Symbol.