I am able to reproduce a bug I previously thought was my mistake, where the overrides of a nested component variant do not propagate changes to a child instance.
See screen recording for behavior
Reproduction file
Please fix, this is a huge pain that is hard to track down.
Perhaps a workaround is for you, which is to change the value of the text directly in the variant, and not in the instance that is in the “Form” component.
@tank666 Thanks for the suggestion. This here is an example that is explicitly simplified and created with a sole purpose of demonstrating the bug.
The actual production design consist of a form with a total sum of 90 tooltip instances across all of the variants of the Form. Monday this single form will undergo a review, meaning changes will have to be made an additional 90 times.
Tooltip and similar components like checkboxes, help-icons, grid cells and headers and basically every nested component that includes text is vulnerable to this bug. Our design system usage is growing fast across the corporate environment. We cannot afford to have this bug around, nor can we afford not to propagate changes from master to instances.
Your tooltips won’t be unique for each input?
I edited your file and now the override is working.
Design file:
Change the Active property of the Form instance.
Your tooltips won’t be unique for each input?
No. This demo setup does not reflect the actual functionality (at all). It’s just a random choice of components to show off where things break.
In production the Form contains 6x checkboxes, each accompanied by an [i] icon with an explaining tooltip. For this we have 6 different tooltip contents, defined once in the master Form. 90 Instances of Form are used to interactively demonstrate how Form adopts (gradual exposure) to the checkbox on/off state combination. These Instances of Form should not have their own text overrides for the reasons mentioned in the previous message. It would simply be ridiculously hard to maintain on each change. That is also why a form has a master with 1 variant instead of 90+ variants for each checkbox combination, like in the file edited by you. We want to define tooltip content 1x for each time we decide to change the text, and not 90x.
And this is just one single form. Scale up the scenario: Our onboarding flow consists of 9 steps (1 step=new form). This bug touches more than just tooltips. It touches every component with text in it.
I do appreciate all the intent to find a workaround until the bug is fixed. Unfortunately, this is not something that would fix anything on our scale. This must be fixed properly in Figma code.
Recheck the file. I added more Form instances. Everything works as you need. When changing text in one variant of a component, all instances of that component accept text overrides.
I added more Form instances. Everything works as you need.
It doesn’t work in your file either. The bug is repeatable in your file the same way as in my original file. Please see the screen recording for the reproduction steps. Just toggle the switch on in one of the instance after you made a change in the master.
Don’t select a Switch instance.
@tank666 Please re-read this:
In production the Form contains 6x checkboxes, each accompanied by an [i] icon with an explaining tooltip.
Form must not have variants, because if it had, then there would be 6^2=36 Form variants, each containing 6 tooltips. Where your example contains 1 single point of change, our real design would contain 36x6/2=108 points of change (places where we must manually type the new text using keyboard) if we were to apply your approach. Which defies the whole purpose of having a master Form component at all. As I explained above, we have 1 master so that we don’t have to push a change hundreds of times by hand.
@support @anon21722796 Can any of you please respond with “we heave read and acknowledge the bug”?
Refreshing the thread ⟲
Still refreshing ⟲
Figma doesn’t respond yet. It’s getting awkward.
This forum is not for reporting bugs, if you think you found a bug you need to report to Figma support team via the bug report form.
@Gleb Thank you. Finally someone replied.
I’ve reported multiple bugs using that form and never got a reply on any of them. Also visiting tickets doesn’t work from the link received in the email. The links point to a 404 page that says:
“The page you are looking for can’t be found. Try searching for something else!”
I filled it once more now, but at this point I’m not sure it even works. let alone that anyone reads those.
You need to log in (press sign up in the top right corner), then you should be able to view your tickets.
You can also use the in-app contact form: ? in the bottom right corner.
@Gleb The Not found page shows regardless of being logged in or not. It’s always 404 and I never get to see the submitted report.
Don’t click the link in the email. Go to https://help.figma.com/hc/en-us/, then click sign up/log in until you see the photo of your profile in the top right corner. Then go to https://help.figma.com/hc/en-us/requests/ to see your tickets.
@Gleb Just wanted to let you know: today I’ve submitted another bug and I am able to view that last one using both the link in the email, and it is listed under /requests/ URL.
None of my previous submissions are listed, nor accessible from links inside automatic emails after submission. So I can’t access the above bug report, even though I got ID and already got a reply on it from an actual human. (which is great on its own)
Thanks for your help. Something got fixed, but not for previously submitted reports.
Maybe you submitted the previous ones with the different email, so they didn’t end up in your account? Or it’s a bug in their system, there are lost tickets sometimes.