Have the same issue, since Figma Config features rolled out.

Thank you so much mate! 🙏🙏🙏 Worked like a charm!

Even the animations weren’t performing correctly before. Now they’re behaving exactly how I wanted them to be.

You saved me from embarrassing myself in front of everyone. Haha Thanks!

Please roll back this feature. The naming convention thing is not a sustainable “hack” for us to use. I am trying to open an overlay in a manual position on the page but it keeps resetting the scroll position. The name of the page(frame) is “Home” and the overlay frame name is “Dropdown” but its still resetting the scroll position. Please roll back! So frustrating.

This…does…not…work, and is not solved. PLEASE roll it back! It preserves scroll in one direction, and then not the other. It’s buggy, unpredictable, and so unbelievably frustrating! I keep hearing Figma team responding with “We wanted…we wanted”, but it’s not about what you want, it’s about what works and is useable, and this is neither of the two.

Please at least give us the option to use a checkbox as well. If it was solved, people wouldn’t still be complaining.

I agree, it’s not solved.

Today I added another pop-up component to my prototype.

Now opening this with those settings:

Scroll state property is the one you currently parse out of the name. “root”

Btw, its bug for sure, since if I create totally new project with the same settings, I get different results.

I don’t see how this is ‘solved.’ Here is another feature where naming conventions control behavior; this highjacks loads of characters in the name string which is not always fully displayed

This is ridiculous.

How can we revert back to being able to preserve scroll. FIGMA YOU ARE CAUSING A SLOW DOWN IN PRODUCTIVITY! PLEASE FIX THIS. I SHOULD NOT HAVE TO RENAME ALL MY LAYERS!

This worked for me too, thank you!!!

I didn’t see how this topic mark as solved.

Figma, you make me confused and furious when building a prototype with your new rules for preserving the position

I just want to make a prototype in peace. Usually, I don’t care about the naming. I just put it “Android,” and it’s done.

Why make people’s day harder?

I sent this message to Figma Support, hopefully they hear it loud:

Heelo Figma,

I’m making a prototype and I’ve seen you’ve changed how “preserve scroll position” works.

I have read online your guide on the new state management and read some discussions on the forums.

I have to say I’m really unhappy with this change. Despite reading that all top-level frames had to prefix-match, it took me a while to figure out that the nomenclature I was using did not fit your idea of “prefix”.

My frames were named Portfolio - 142, Portfolio - 143, Portfolio - 144, etc.

In my mind these have the prefix matching, but it wasn’t the case and the scroll position kept resetting.

It seems unnecessarily aggressive to force everyone to use a very specific (and unclear) naming structure to make it work as expected.

The old behaviour was perfectly fine, I had clear control over what I wanted.

My vote is to revert this.

This change is really poor.

• You’re forcing everyone to use the same naming structure. Don’t. Let me name my frames as I like.


• It’s opaque, hard to debug despite reading your guides


• It removes user control. Just don’t.

If you want to infer a default from naming, then it should be reflected in the interaction settings panel where I can see it and change it.

I’ve spent hours trying to figure this out since just the naming conventions (albeit time consuming to adhere to) is simply not enough to get it working. We’ve completely halted making useful prototypes for the time being as it’s simply a time waste.

It seems to be whenever there is content below the expandable content that the instant scroll to top occurs.

I’ve set up a simple example of when it works and when it doesn’t.

Prototype of where it does jumps: link

Prototype of where it does not jump: link

Link to the design file: link

I’m sorry, @erik23 — but both of those prototype links seem to be working for me as the animation is based on the interactive components and there are no frame to frame interactions in which the scrolling would be reset?

Do you have a recording you could send me to niko@figma.com or maybe some other example in which it resets when it shouldn’t?

And I did want to respond to a few other folks here in this thread who complained about using top level frame naming to handle this;

• First off: We hear you on the layer naming being hard to discover and disrupting for some of your existing workflows. We’re sorry about that!

Some more context on why we made that decision:

• 
  

  We wanted to add the functionality that when you return to a screen in which you had scrolled before, you essentially “re-open” that scrolling state. (Imagine a list of products, where you scroll down, click to open a detailed page, and then click “back”. In the past we’d always reset the scroll position back to the top.

  
  


• 
  

  We also wanted to make this work for interactive components and for videos in the same way, rather than have a special case just for scrolling.

  
  


• 
  

  The solution we ended up was layer naming to functionally group top level frames and make all different options (preserve scrolling, reset scrolling, reopen scrolling state) available — as it’s the same way you handle this for videos or interactive components inside of top level frames.

  
  


• 
  

  We did look at a bunch of different options (like separate actions, relying on sections or actually “grouping” frames, or even adding a second layer name, but felt that a simple layer naming schema was the option, that introduced the least amount of complexity and was the most consistent with the rest of Figma.

  
  

Again, we’re sorry this is causing disruption!

We do have some ideas on making this more visible or accessible (e.g., by allowing you to see what is about to happen in the interaction dialog as @Alessandro_Suraci1 had proposed, or by somehow visualizing this on the canvas and making it easier to edit), but I can’t promise you when we’ll get to this. We hope you understand! And we promise that we do want to make Prototyping simpler and easier!

If you run into functional issues, like the scrolling resets when it’s not supposed to, even if everything is named correctly, please keep sharing those, so we can debug those cases! Thank you!

Hi folks, if you’re still having issues with this the fix that I’ve been using is this: name your top level frames the same thing, but separate them by adding a slash and then the number in the flow. I.e. if I’m creating an onboarding flow, I’ll name it ‘onboarding / 01’ and the next frame in the flow ‘onboarding / 02’, which seems to have it working as before. It’s not ideal, but it’s better than nothing.

No idea why but it works. 😃

I just added a damn “/” in front of the numbers and it preserves the position again.

Thanks!

Have you found a solution for this? I’m having the same problem and you stated the problem best. I want Page B to MATCH Page A’s scroll position not remember it’s own scroll position. Please let me know if there’s a solution to this problem. I’m having this problem when I have tables with tabs and I want page B to match A’s scroll position without this jumping feeling.

This behaviour is indistinguishable from bugs and impossible to deduce from the UI. Well meaning users are going to break each others and their own protos constantly by giving frames useful names.

Seconding the comments here that the layer naming “solution” is not a solution. Pretty much every frame in a prototype is now resetting to the top. It’s very unintuitive to have to change that layer name on every single component that expands contracts, shows, hides, etc.

This is one of those moments where users decide to look elsewhere for a different product. The interaction cost for having to rename layers is extraordinarily high for something that could be a single-click selectable option. It’s also not heuristically obvious how to do this, even if it was worth the time (which it’s not), and is experienced as a bug. By stakeholders in presentations it’s viewed as sloppy design which reflects poorly on the designer.

Yeah, I’ve been reporting this issue since the change happened and despite Figma updates, still no proper fix!

This is beyond frustrating – something designers have to do every two seconds has a multi-point typing interaction and is completely unintuitive. It looks like most people still don’t understand how the solution works, even with the explanation. I have components expanding and contracting all over the place.

Totally agree!

We have an Organisation plan which has a big budget implication!

Sort it out Figma

For sure. This is one of those painpoints that’s existential for customer retention. They seem really happy with their solution though.