This is just horrible. Figma is becoming a very convoluted tool. I don’t event know why I’m bothering with prototyping here. I’ll just use marvel.
Hi, we made the changes to preserve scroll position, to make it more consistent & we’re sorry for the disruption! To be clear, since May 24, scroll position of top-level frames is preserved automatically when they have identical names OR a shared prefix followed by a forward slash (e.g. “Checkout/1”, “Checkout/2").
Any new interaction automatically follows new state management rules. To update an old interaction to the new state management controls, click the Update button on the Interaction details modal.
This help center article will help you quickly update your frame names for an existing prototype: https://help.figma.com/hc/en-us/articles/360051747774#Changes_to_preserve_scroll_position
If you still have questions, feel free to reach out our support team here: https://help.figma.com/hc/en-us/requests/new?ticket_form_id=360001731233
Give us the ability to preserve scrolling position without having to rename the frame. The fact that you closed this topic just to not have to deal with angry people says a lot about you and how you handle feedback from the community. Your ‘frame naming solution’ is ridiculous. No one is gonna rename their infinite number of frames. The fact that you refuse to fix this boils my blood and I hope you resolve this issue instead of sweeping it under the rug like you did with the previous bug report with this title.
Hi there! Thanks for your feedback. We hear you, we will pass your feedback to the team for consideration.
I switched your topic as “Share an idea” so we can gauge the overall interest in the community.
it’s not “an idea” it’s a bug and you need to fix it! so so many people wrote on the original post that they’re incredibly frustrated and all you do is avoid the topic! Instead of rolling back the feature you keep ignoring it as if everyone’s fine with it. we are not fine with it and the original post made that very clear!
We understand your frustration and really appreciate your reiteration on the feedback around the preserve scroll position feature.
We are glad you’ve kept an eye on the developments of this particular conversation and would simply like to reiterate our official position on the matter - we made the changes to preserve scroll position to make it more consistent.
Since our teams concluded that this was an intentional change (i.e. planned as a feature change internally) rather than an actual bug, we’ve solved the original topic (for that reason and that reason only).
However, we have been paying close attention to the community sentiment around this topic and are keeping our teams informed. Please let us know if you have any other feedback or arguments that you believe would help us strengthen the need to roll back the feature or further improve it.
Thank you for your understanding, we appreciate your collaboration.
@Figma_Support – What is most frustrating is you are making people dig through forums to figure out how to make this new feature work properly with their existing prototypes. Why is there not some sort of visual indicator that your Frames are not named correctly for this new feature to work? When the Frames that are not named correctly bounce and jerk around it sure makes it seem like a bug which is why so many people came here thinking it was…
Since we are forced to follow a naming structure, can the selection dropdown within the prototype interaction box be WIDER? I’m using short words and abbreviations and I still can’t see enough.
It is also frustrating that I can’t use the scroll wheel within this dropdown menu, and the interaction box appears all over the page instead of the old spot of a fixed position on the right.
@Figma_Support
To my mind, you can solve half of the troubles here by blocking the Y movement on an auto-layout frame used as a screen in the prototype. As you know, if scroll vertically is set to this screen, changing the size of a contained component will adjust the height of the screen too.
Defining the auto-layout height as fixed, solve a lot of bad reset scroll position behavior.
The origin of the auto-layout frame as screen must not move in prototype view.
As suggested, I have renamed all my top level frames. That didn’t work for me. Is there another work around? Because half my prototypes are unusable with click states being held hostage below the fold on smaller screens. This is crazy!!!
@Melissa19 — Thanks for the feedback! We’ve fixed this and extended the width of the dropdown you were referring to!
@Danny7, do you maybe have a screenshot/example of your top level frame names and the interaction panel for one of those interactions that don’t work. To be clear “Reset scroll position” should NOT be checked, if you want the state to be preserved.
@nikolasklein These are the frames I am linking together.
Buyer / Rate Group links to Buyer / New Rate Group as “On click… Open overlay”
Buyer / Rate Group scrolls just fine but as soon as the overlay is opened… everything locks into position, despite following instructions to keep frame prefix the same. On smaller screens this make the prototype unusable given that the Submit button (in the overlay) falls outside the browser view so user can’t scroll to see and click to forward the prototype.
Oh, I see! Yeah, that’s actually a different limitation, unfortunately!
While an overlay is opened, no interactions in the original frames are working. This includes things like interactive components or, in this case, scrolling that underlying frame.
That’s actually independent of the questions in this thread about scroll preservation / state management across frames and also independent of how your frames are named.
Sorry about that limitation! It’s something that we have on our list to take a look at again. Depending on the prototype, you might be able to work around this by using interactive components for what you’re trying to open.
Alternatively you could make the overlay itself scrollable, but unfortunately you can’t adjust the height of the overlay based on the user’s viewport yet. (Also something we want to fix!)
My frames are already exactly the same name. I made a component out of the entire page and each section on the page has different variants. When I click to another instance of the page (Component) it still scrolls to the top. This is super-frustrating.
I don’t really understand how your frames are set up, @Mackie_Benjamin. Is there any way you can share your setup of components and frames on the canvas?
PLEASE ROLLBACK TO THE OLD PRESERVE SCROLL!!! Is very anoying the “new feature” 😦
Continuing issues… please rollback to old preserve scroll … in not solved yet
my case was a gallery like grid and a list, just called the same name for the 2 frames and everything worked perfect.
I am trying to get a prototype ready to ship, and no matter how many times I review my frame names to make sure they are consistent, clear all of the interactions and start over again, or clear my browser cache, the prototype still jumps all over the place. It’s down to the last two hours of the workweek, and I’m ready to tear my hair out.
Wondering why there cannot be three checkboxes on the interaction modal with these choices:
- Preserve scroll position
- Reset scroll position
- Reset component state
Totally agree!
C’mon @Figma please make this easy adjustment and save everyone!
the prototype still jumps all over the place
@SP13 — Sorry this is happening. In cases it is happening for scrolling containers inside of top level frames: they need to match to each other across frames. Read more about matching of nested objects…
If it’s not scrolling set on nested objects, could you send a screenshot or sth and I can see if I can reproduce it.
Wondering why there cannot be three checkboxes on the interaction modal with these choices
We’ve actually thought about this , too, but there are two reasons why we didn’t end up with this:
We wanted to have the ability to “remember” a screen at the position that you were scrolled to. (Imagine a long list of products that you scroll down. You click on one and you go back; Normally you’d be back at the top, but real apps remember your scrolling state.) —> That’s not possible just with “Preserve scroll position”.
We wanted the system of State management to be consistent across all “interactive elements”, so it works the same for Scrolling, Videos, and Interactive components. And given that “Preserve video position” or “Preserve interactive components” wouldn’t have worked for the same reasons as in 1., was another reason to go for the new behavior.
I hope that helps a bit in understanding why we did this change, but yeah, we’re very sorry it caused this much confusion during rollout on this and we learned a lot of what not to do when changing behavior in Figma.
If you have cases where it just doesn’t work, LMK and we can take a look if anything is buggy.
Context: I was the designer on this feature.
@nikolasklein Thank you for responding - I wonder if you could put out a tutorial video about the new feature, showing step by step how to use it. This would be a huge help.
@SP13 — I’ll ask! We have a new Help Center article about State management that goes quite into detail about how it should work.
Let me know if that’s insufficient!
My prototypes are also unusable. I’ve spent a half an hour trying to make a simple interaction work. Digging through dozens of frames to try and diff the layer names to make sure they are identical… extremely frustrating. Especially when it appears all of these dozens of layer names do in fact match — but it still won’t work. I’m beating my head against a wall over here for what used to be an easy thing to manage with a checkbox click.
I would also appreciate a rollback to the previous implementation of state management, where scroll position was managed with a checkbox.
