Same ! It’s a terrible update. How to ruin your work when you have to present a prototype 😦 😡
Fix this issue! Supper annoyed!
This update is not making our prototypes behave in a predictable way when walking stakeholders and clients through them in a demo situation. It’s very jarring when the page unnaturally jumps to the top.
The suggested ‘fix’ to name the top-level frames the same works but as others have pointed out, is not ideal when you want to give different names to identify each screen for organisational purposes. Unique frame names help during construction of the prototype. We have ~20-60 frames and with the same name we’ll have to guess which is which in the interaction details menu.
Agreed, the best solution is to just keep the ‘Preserve scroll position’ checkbox and make it checked by default regardless of same frame names…
I’ve had to complete re-work my prototypes and they’re still not 100%
I am having the same issue on all my prototypes. I have tried to go fix and update the interactive components and the wired interactions, but on anything that was built prior to the update the scrolling is bugged. I even tried re-wiring the entire prototype from scratch again, but still didn’t fix it. Please Figma, PLEASE roll back this feature or figure out a fix. I don’t want to have to rebuild all my designs from scratch…
Gosh))) it’s been like 20 days, that’s something super easy to fix. Guys, if you think we will used to it, unfortunately no… How long to wait when my proto’s going to be fixed?
I was having the same issue but the note from support above really helped for my NEW protoypes.
Essentially the only part of the artboard name that has to be the same is the beginning if the artboard, then add “/” and everything after can be unique. SDo you dont have to have 30 frames with the name “default load”
I just renamed all my desktop frames
DT/default load
DT/input open
DT/tooltip
You get the idea. Anyway, it fixed everything and it works perfect now.
The thing I’m dreading is going back over older prototypes.
@Figma_Support we need an update. Are you rolling back? How long will it take?
We need a “Preserve Scroll Position Across Pages” that is separate from the new State Management settings. I don’t want Page A to remember its scroll setting and Page B to remember it’s own different scroll setting, I want Page B to MATCH Page A’s scroll position when I navigate to it.
Expecting users to use a naming convention when it wasn’t required before is not a good practice, and even if the naming convention is followed it doesn’t work as outlined above.
lost a half day’s work today thanks to this. And not working at all despite the workarounds suggested above. If anyone from Figma is reading this … here’s a golden rule for you: don’t fix what ain’t broke. I’ll be raising this with my team tomorrow as an example of extremely unhelpful UX ‘design’.
… still struggling with this, Figma folk … I am now going to have to postpone a whole week’s worth of scheduled UX Research testing due to this issue. This just to give you insight as to just how unhelpful this particularly bewildering ‘innovation’ to your experience is.
There are quite a few incredibly horrible things with this Update. When building frames for a sequence of screens. My agency and practice will Label the screens with an index number so that we can audit and see screen sequences in the layers panel. For example, if I have a login sequence we will name them Login-0.1, Login-0.1.1, Login-0.1.2, and so on and so on. We can no longer do this because all the screens have to have the same name in order for the Scroll position to remain in place. Or add a “/” between a name and an identifier. I can’t tell you how many prototypes are now completely ruined and will require someone to go in and manually correct screen names. And now that all my screens have the same name this makes it more likely that my design team will mess screens up when using the layers panel. HUGE MISTAKE ON THIS UPDATE. Thanks.
I am having the same issue.
In my POC you have to scroll down the web page to see a list of links — each styled as an individual frame. When I hover over the link I just want to show a simple smart-move interaction of the arrow icon in the link. In order for this to work I need the scroll position to stay put.
I have tried removing all of my nested frames so they are all stand-alone with no parent frame (before I had them all grouped in one parent frame like a section). These are not interactive components, not even components. They are just individual frames with a small move that I am trying to POC between two pages of a website on a hover.
As suggested, I renamed the 2 interactive frames that need to show this interaction so that they are named the same and are not sharing names with any other elements on the page. This is confirmed by the UI when I select one the other is highlighted.
And it still does not work.
This is perhaps the most simple type of spot-comp prototype I can imagine.
Please fix this fast or better go back to the what we had.
Please help! We still need the ability to preserve scroll function. This is an important piece of the design puzzle for prototyped components.
Yes! I don’t get why they changed it in the first place
Does anyone on the @Figma_Support team even reads these forums? it looks like they’re ignoring this… What needs to happen in order for an issue to be resolved? a certain number of votes? because that’s a bad metric to judge an issue by. Esp one like this that one must purposely google in order to find out that many many other people are having the same issue and it’s not something they did wrong. How many people need to virtually shout at you so you’ll fix such a major issue? I wonder how you people create your prototypes after this change since it takes about 5 seconds of prototyping to see how broken the scroll feature now is…
Related/Not-related. FWIW, I fixed my problem by removing the AutoLayout on my Frame.
Why? WHY? WHo asked for this?
Did you even test it before rolling it out?
@Figma_Support do you have any workarounds for us in the meantime, until you fix this?
The same naming and placement didn’t work for me either. Any other ideas? Bug is still present
I’m still running into issues with the latest State Management feature release, also. @Figma_Support Please roll back ‘Preserve Scroll Position’ or fix this issue as soon as possible. The latest change isn’t working as specified within the document as outlined here: https://help.figma.com/hc/en-us/articles/14397859494295. Thank you!
Please roll back ‘Preserve Scroll Position’! It’s not sustainable to name all the frames the same.
Plus one here please - totally confusing!
The scroll portion is maintained only if you have layers named in a specific order.
“Top Frame Name”/“Another Label_1”/“Another Label_2”
If followed the above format for naming the frames it will preserve the scroll position.
Example:
Frame 1: User
Frame 2: User/Add New User
Frame 3: User/Add New User/Check Existing User
Frame 4: User/New User Added
Since all the frames have “User” present in it, now the scroll position will be preserved.
