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

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.

This is impractical and I wish people would stop suggesting it a solution. if you’re working on a large project with many frames it’s unreasonable to name frames this way. The solution should be the responsibility of @Figma_Support to roll back to the previous version. not on us to change the way we work.

Totally agree with you!

Am i crazy or does this entire new feature just work intermediately whenever it feels like it? Even opening the wrong frames entirely.
Even after editing frame names ?

For example I have a frame (frame / 1) when you click a button it opens an overlay (overlay/1), after delay that navigates to (frame / 2), for some reason instead it navigates to (frame / 1). After changing (frame / 2) name to (TEST_FRAME) it worked just fine and navigated to the right frame (minus keeping the scroll position, because tis not the same naming convention anymore).

However this flaw does not stop there. After changing (TEST_FRAME) to (SC_FRAME) it reverts back to going to (frame / 1 ) after the delay. It makes zero sense, the only thing i consider causing this would be if there was already a (SC_FRAME) naming convention being used somewhere, however there is not at all.

Please let me know if anyone else has encountered these bugs.

Yup, me too

Anyway around this that you heard of or tried? I keep on trying to break the bug basically, and its so frustrating when trying to actually test. I loved this product before the change, but it is essentially making things just not useable.