Skip to main content

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


Show first post

209 replies

Tamar_Ziri

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.


Livia_Biondino

This is so frustrating, I don’t understand why Figma would remove this option?! @Figma_Support is there anyway of getting this crucial option back? I have to present to a Senior Stakeholder tomorrow and this breaks the journey so much by shooting to the top of the page each time a link is clicked


Tamar_Ziri

it’s horrible and they don’t seem to care at all. is there anyone else we should be tagging besides @Figma_Support ? I’m sorry about your presentation


So glad I found this thread as I thought I was going crazy! I hope they get this fixed soon …


Gabriele.B

Please address this, it is so annoying. Prototypes with opening accordions are completely broken now. The only workaround I found is to have different “pages” with the same name, but it’s not something that can be done easily throughout a whole project.


Agreed! Please fix this Figma


RobW
  • New Member
  • 3 replies
  • June 23, 2023

This is the single most annoying bug/update that Figma has introduced. All my naming conventions are correct, yet this is still a problem. I have prototypes that no longer function as expected and I am losing confidence from stakeholders.

We need a fix or a rollback of this ridiculous update immediately.


Jorrell
  • 1 reply
  • June 23, 2023

It works! Thanks! Although I’m also not familiar with the dash (/) usage.


Grady_Mark_ESI

The naming convention fix only works if your page designs are wrapped each in a frame and the frame is named with the convention.

Even so, this is not a sensible or desirable way of working - for a company that makes the most used interface design tool in the world, surely your own primary UX rule should be “Users shouldn’t need to read the manual”?


Tia_Escobar

The new way this works with State Memorization requiring frames to be named the exact same is a problem when moving back and forth between page states. For a pricing page that has different product categories (business vs ecomm) and term lengths (monthly vs yearly) it makes clearly naming frames in the design file impossible. Is there a different way to do it? Can you add Preserve scroll position back?


john-mainboard

At least tell us what is wrong and how to fix it upon opening the File and tell use how we can upgrade it, or do it automatically and add your /1 /2 after the frames.


Anne_Birzin

Also having this issue. Can no longer preserve scroll position in prototypes. Please fix


Maria_Zenkevich

Seem like a bug still. The mental model is already set that the scroll is preserved independently from the art board name. So, it seems like an unnecessary constraint and an additional mental load … vs it just worked before… I also am hesitant to use the new structure since I do not know potential implications of using “name” / “subname” for art board frames. .


JoeyLing
  • 1 reply
  • June 28, 2023

Pls fix this problem ASAP, it’s very annoying.


Jake_K
  • 3 replies
  • June 28, 2023

+1 to these complaints. Why did you make this change? It broke all old prototypes using this feature and the new “default behavior of always preserving scroll position” doesn’t seem to ever work right. It’s not always possible or practical to name all of the layers similarly, esp when working with multiple complex symbols. Yet another instance of Figma making a sudden decision with no warning, and seemingly no user input, that breaks hours of work, with zero regard for the needs of paying customers.


This just broke the presentation I have to present in 3 minutes…


Tamar_Ziri

THIS!
(And yes, I will keep commenting until you fix this @Figma_Support )


Julie_Turgeon

+1 to all of the above complaints. An extremely frustrating experience. I’ve spent hours trying to fix prototypes that previously worked perfectly.


Completely agree with you


So you’re telling me that I have to redefine my entire naming structure to now comply with an arbitrary requirement that wasn’t there before the last patch? Preserve scroll position worked great and I had the flexibility to use my own naming scheme. Now ALL my projects are broken because… WHYYYYY?

I can’t even begin to figure out how long this is going to take me to rectify.


I had the same issue… Please fix this. It’s really hard to name frames by some specific ways. I got crazy trying to find what’s wrong with my animation…

Thanx guys from this branch for helping, but it’s still 😪


Reply


Cookie policy

We use cookies to enhance and personalize your experience. If you accept you agree to our full cookie policy. Learn more about our cookies.

 
Cookie settings