SOLVED - Preserve Scroll Position (please roll back the feature)

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 [grrr]. Please explore other taggings that don’t require us to follow specific namings; designers and devs indicate all kinds of things there. Aside from that rant, my very long lists will. not. behave. even though layers are named the same, in the same order, using the same components, since they are copies of each other with items checked and unchecked (yeah I know this is the dumb way but it works). If naming conventions make me check thousands of layers I can see how that could inspire new plug-ins but hey… I’m with the other posters, this is a hostile update.

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!