Autolayout bug in nested components

I noticed a bug that has recently appeared sometime in the past two weeks dealing with autolayout and nested components.

Our team uses master components so that we can push style changes to all variants quickly. It works great and helps keep things tidy. The only issue with this is that if you want a full-width component (for instance, a button you want to expand to the size of the mobile screen), you would normally have to take these steps:

  1. Drag a variant instance onto the frame
  2. Double click to go from the variant to the master button frame
  3. Change Resizing from ā€œHug Contentsā€ to ā€œFill Containerā€
  4. Adjust the width of button width as necessary

This has historically worked but now whenever these actions are done, trying to set any Resizing option automatically chooses Fixed Width. This breaks resizing nested components.

You can view this process in the video below. I created a new master button and a small variant set, and then show how the base button width responds correct, but the variant button instances cannot be changed to a different resizing option.

Autolayout Resizing Issue

This effectively breaks many components in our design system, which is probably also breaking other users that employ similar component creating techniques.

Again, this only started happening recently and seems to be a bug in the software.
Is there a fix in the works on this?

8 Likes

Experiencing the exact same issues with my libraries and components rendering most of them broken/useless now (I filed a bug ticket with Figma already). Also hoping for a fix soon as it does seem like a particularly nasty bug :grimacing:

I have found a temporary fix (that long term might cause more issues) :

  • select the nested component within the main component that wonā€™t respond to auto-layout overrides anymore (sometimes this means selecting multiple nested instances and performing the steps below)
  • choose any different auto-layout prop than it currently is and then switch back to what you want it to be by default
  • youā€™re effectively creating an override state here within the main component on the nested component that figma can recognize and respond to again.
  • now your instances auto-layout properties will be able to be overridden again as it worked before
  • but be careful as you will need to do this trick on both axes (width and height) if you want those to be able to be overridden later and this can create problems with children as sometimes this forces them into different auto-layout modes such as fixed (you can reset/fix those too of course, but these are also then treated as overrides as well ā€¦ so you just need to be aware that causes problems too potentially)
  • this also means that your original main components auto-layout props are no longer connected to your nested instances anymore as they have been overridden, which breaks a lot of utility of using nested components in the first place and its pretty time consuming / impossible on very complex large libraries to do this without breaking a lot of stuff.

Update: recorded a video demo of the above method but canā€™t post it because iā€™m not trusted enough to post links (support is looking into it, hopefully can post it soon)

1 Like

Here is a short video showing how to do the ā€˜fixā€™ outlined above:

2 Likes

Iā€™m also getting this bug and this in making a lot of components in my Design System unworkable. I am now forced to detach instances which is :broken_heart:. Hope this gets addressed ASAP.

1 Like

I also use master components in the same way as OP. My design system is also being impacted by this bug. Really frustrating.

At least someone else is experiencing it, because I thought I was going crazy for a bit there.

1 Like

Got an update on my support ticket from figma and they have identified the issue and are working on a fix! :tada:

3 Likes

Have they provided any ETA?
Iā€™ve been wrecking my brain for the past few hours trying to figure out what was wrong. and unfortunately its still not fixed :frowning:

Iā€™m also being affected by the issue.

I just ran into this issue as well. Is there any traction on a resolution?

I initially heard from support with a solution to try, but it didnā€™t remedy the issue. Iā€™m currently in process of being escalated to the engineering team, so no fix yet.

This sounds like a bug that was reported recently where attempting to change the constraints seems to not behave as expected.

Iā€™ll be noting your encounter on this bug report. Iā€™m afraid there arenā€™t any workarounds for this, but it appears a fix will be released soon as our team has been investigating this.

I recommend testing this once again by the end of this week ā€” If the issue persists, please feel free to reach out to us and weā€™ll follow up with engineering.

Thanks for your patience as we work this through!

1 Like

I received a response from support that this problem has been fixed, and I just tested it out. Everything is working and back to normal for myself - I hope it is for everyone else!

4 Likes

Yes, can also confirm everything works again, huge relief!

1 Like

I am still having issues. Iā€™m trying to understand if this is related to this bug or not.
any help would be greatly appreciated.

Basically Iā€™m using a ā€œPlaceholderā€ component nested in another component and I want to be able to swap out the placeholder with just about anything else, and have the parent component adapt according to what is inside of it.

Iā€™ve explained it in this video.

Ignore comment aboveā€¦ I fixed it by wrapping the contents items in another frame with autolayout and set that to ā€œhugā€.

Carry onā€¦ Nothing to see hereā€¦

3 Likes

Iā€™m having issues with this. Auto-layout is only working in the main component, not the instance. See video

2 Likes

Having the same expanding menu as you and the same problem!
Did you solve it?

I havenā€™t solved it :frowning:

1 Like

Hi @Alice_Holm , posted my similar problem here and got a solution for it! Perhaps that also solves your issue.