I also have this issue, have you found the fix yet?

Me too. I was having the same issue and I was wondering if I was doing something wrong.

I have the same 😦

“the top level frame name should be identical with the target frame, otherwhise the preserve scroll won’t work.”

It works for me

also have this issue, have you found the fix yet?

testing this

Me too. I was having the same

ddahdkahdkadkahdkadhkahdkahdadkdahdjahdjhadjadjajdajdbjabdjabdjabdjabdjadbjabdjabdjadbjadbjabdjadjabdja

I was having a this problem and after some troubleshooting, I realized that I had a frame (in my case, this was a background design) that wasn’t set to Clip in the same size as all the other frames I was prototyping.

TLDR;Making sure all my frames, groups and autolayouts were clipped in the same size fixed this issue for me.

OK. Bit annoying but tested. I had this issue with smart animate within a mobile prototype that jumped to top/didn’t maintain scroll position; made sure frames were in the same name and position, and even tried evening out the outer frames (‘pages’) height. Didn’t work.

FIX: I renamed the artboard/pages frames - to the SAME NAME; it works like magic.

format should be “FrameName” or “FrameName/Name” (the issue here was that I used dash “-” instead of slash “/”, use Slash).

I Hope Figma would fix this transition regardless of frame names.

I don’t understand your solution - you’re saying you’ve renamed the frames to the same name, but what if I’m having this issue with a component on a single page? There is nothing to rename there, I’m assuming your problem was between multiple pages somehow, but I’m having this issue while staying on one page and simple clicking between two variants of a component.

True, separate pages. However I also encountered similar issues on multiple components within a single page, in most cases the issues were with components with multiple variants and inside elements with auto layout. Try breaking apart or place complex components outside of autolayout elements, might do the trick.

That’s going to be a problem, because I need the auto layout for the content to be pushed. Essentially, I’m in a very similar position as OP, and it’s frustrating. Not a big deal, because it’s just a prototype and doesn’t have to look perfect, but it’s a shame that there are so many bugs in Figma.

I suppose I’ll try breaking down the components within components that I have and see if anything changes. This is what I’m opening up, and all those checkboxes etc. are components.

Was having same issue (jumping up and down, on same page, with auto layout).

Seems like having a fixed height on the main container fixed it. So try the following:

1. Add auto-layout on the main, outer most frame (let’s call it “main-frame”).


2. Set the main-frame’s height to “Fixed”.


3. Adjust the height of the main-frame to match your prototype device size. I typically use 1440x1092ish. So, 1092 height.


4. Uncheck “clip content” on that main-frame. (Not necessary, but allows you to see what’s below the cut off height.)


5. Check that it’s working as intended.

That fixed the prototype animation issue for me. Unfortunately, the editor view doesn’t look as slick now for the devs or presentations because the content is spilling out of the main-frame container. This can be managed though by having a separate file for interactive prototype that only you’ll see.

Thanks for this. Feels pretty silly if I’m honest, but this helped me fix the issue.

When it comes to things spilling out of the main-frame container: Turning off “clip content” on the main frame and allowing vertical scroll overflow allows for the entire page to be viewed. Just need to ensure that the auto layout / hug frame contained within the main doesn’t also have overflow and you should be good

In short - using auto layout with the main frame seems to be the culprit with my use case

Thanks, Brian

Wow… Tried to recreate the issue and could not until I turned off scroll overflow again. Appears that the extra nesting (in this case anyway) wasn’t necessary as it seemed. I can watch the issue arise and disappear each time I turn vertical overflow for the main page

Conclusion - Main frame can be auto layout w/ hug as long as scroll overflow is turned on

Wow this worked… ty!

Thank you, It’s fixed mine

Thanks Brian! This fixed it

thank you, making the overall page/frame names the same did fix it for me.

very annoying though since having a bunch of frames with the same name also makes it hard to link to the correct one if you’re scrolling through the options of which screens to navigate to for the prototype, and also hurts the file organization. i had changed the names for a reason. 😭

I just had the same issue and what fixed it for me was checking auto-layout settings of all parent containers:

This seems to happen especially when you have your main frame set to autolayout for automatic height adjustment (so while designing it adapts it’s height automatically when adding new elements).

My structure was:

→ Main frame (mobile view, removed auto-layout from this for fix)

→ Content frame (Auto-Layout stacks vertically)

→ Fold-Out element (auto animation changes height, content folds out)

Thank you! this worked to rename the page names as the same.

I had same issue with accordion, removing the auto layout really helps! And I don’t know why 🫠

Both “solutions” feel really hacky to me even if they do get rid of the jump.

A bunch of different frames with the same name, OR fixed height parent frame with all the guts of the nested content spilling forth.

So it’s basically picking the least objectionable of these problems:

• confusing frame-naming convention


• overflowing design


• jumpy smart animation

😕

Yeah but then when accordians are opened the main frame doesn’t stretch meaning the bottom accordians go outside the frame and are either clipped (with clipping on) or behind my next section (with clipping off)

Still doesn’t fix the issue that the entire space should stretch without the jump to the top.