VERY irritating UI bug. Has anyone else experienced this?

We have same issue in 2018.1b8 Please we are unable to work on UI almost 3months.

 

Looks like the same issue to me, yes :/. Basically what I did is, I updated our project to p1 so and re-created prefabs for our UI - this part worked like a charm. Then, after opening the project in b8, all elements under prefabs are messed up, same as before (or even more so), without doing anything (not clicking apply / reset).

 

@karl_jones
Just tried b9 and the issue is still there. Why on earth has this been dragging on for so long now? The first repro case i sent for this was 4 months ago (fogbugz 970914) and in total I've sent 3 + a video (as requested by the support) detailing the issue.

Since then it's just been one step forward two steps back. The only fix that actually seemed to do anything was p1.

And it's not like this is a low priority issue that causes some minor annoyance, it's been a complete blocker for anyone using prefabs / disabled elements with the UI, which I imagine is a lot of people - as indicated by this thread.

Come on, the devs, and especially whoever is doing QA on this need to get it together, a bug being reopened once is bad but this is like the fourth time this was "supposedly" fixed, yet we are still experiencing the issue in one way or another.

But the biggest annoyance of this problem is the constant back and forth with Unity. You say it's fixed, we rejoice, download the fix, and then confirm the issue is, in fact, still present.

It's gotten so bad that we started a bet in the office. Every time a new "fix" is out we vote if it's actually been fixed or if it's again just smoke & mirrors.

Please, after 4 months, fix the bug already.

 

@karl_jones
That's great, thanks for the update. We're not developing on beta at the moment (for obvious reasons) but I want to start with the new rendering pipeline as soon as I can.

With those screenshots, my hopes are high for the new beta

 

Is there anything that holds you to send the b10 out please?

 

Ok Friday I will try our music notation system that is using very heavy UI. ( 60 000 UI elements ) And let you know my thoughts on the UI stability and performance. I saw that you fixed the bug that other canvases got somehow dirty by change in one of the canvas. Which caused us a bit headache. Look forward.

 

After updating to 2017.3.1p1 there's still some weirdness going on with UI elements occasionally being misplaced, which didn't happen in the version we previously used (2017.1.2p4).
UI elements occasionally get shifted to completely different positions after changing their content, which was probably introduced with that patch release (doesn't seem to happen with 2017.3.1f1).
Will file a proper bug report with more helpful info as soon as I can reliably reproduce it. Just posting now as info for others who think about upgrading.

 

The problem is somehow related to the ContentSizeFitter component, when using that UI elements can end up in different locations than intended.
It has been reported as #1008747 with a reproduction project.

 

Hello,

I'm working with Unity 2017.3.0f3 and I do have this bug which is really driving me nuts. Which version of Unity should I use in order to have it fixed ?

Thanks

 

I do not see the fix in the patch release not, are you sure about that ?

Thanks

 

Thanks ! It works as expected

 

Experiencing the same issue for what it's worth. We are on 2017.3.1p4 and seeing occasional elements move at runtime when all we are changing is the size of a component.

 

For reference this is the issue in the issue tracker: https://issuetracker.unity3d.com/is...eir-anchored-position-has-not-been-read-first

Looks fixed at least.

 

Im still experiencing this issue on latest version

 

Your other thread, to which I just replied, you stated that you are using f1 not p1 or higher.

 

your right, didnt know patches were different

 

We experience a similar issue since we've upgraded to 2017.4.1f1. When instantiating/enabling a GO and setting its position (not local position) afterward, it's being positioned at the center of the screen for 1 frame. Calling ForceUpdateRectTransforms directly after setting the position fixes this problem.

 

I think you should file a bug report, if that's the case, with a simple repro.

 

So just to be clear, is this supposed to be fixed in 2017.4? Because I'm still seeing weird behavior. If the fix is only in 2018, can we vote to have it pulled back into 2017.4 LTS?

 

@karl_jones can you give an honest answer about the status of uGUI hat the moment? I'm using Unity 2018.2.6f1 and without any effort I already get weird layouting behaviours all over the place.
The Child Force Expand property of the HorizontalLayoutGroup is not expanding the children. It's recalculating the positions, but is not at all changing the size to fit into space of the gamobject with the layout group.
Furthermore, adding a Layout Element with flexible with set to 1 does not rescale the child either.
Only when I tick both, Child Controls size AND Child Force Expand, children share exactly 50 percent of the space each. The Layout Element also does not change anything about this situation using flexible width only.
Adding a Vertical Layout Group to the parent of the Horizontal one and duplicating them is even more fun. Now toggling Child controls size height changes the height completely weird and never back to the height it was before adding it...

I even checked out the Tutorial Video from 2016, creating a vertical menu. All he does is adding a vertical layout group to the parent of 4 buttons and done. Child Force Expand Width and Height are both checked.
If I do the exact same thing in 2018.2.6f1, the buttons share the space equally, but they keep their size. Once clicking on any of the Child Controls Size checkboxes scales them to the full size, which is what those should NOT be doing, right???

Apparently uGUI is broken and I think this happend with the version the additional checkboxes on the Layout Groups were added. Since then, all the weird stuff started to happen...

Can you confirm that you know about uGUIs current situation? I mean it's so easy to reproduce a lot of these problems, it's hard to miss.

 

Yeah uGUI layout in 2018.2 is pretty broken

 

I can try, but I'm not sure if I can distinguish between bugs as I don't know if they turn out to be the same. We'll see. I'll post them here

 

@karl_jones Ok, here we go:
Case 1077920
Case 1077925
Case 1077928
Case 1077938

I stopped there. There's not really a point in trying to get bugs isolated under these circumstances. Since Ctrl + Z does not even guarantee the last state and some layouts just stay in their new fashion, it's all deleting and recreating hierarchies to get the same behaviour going. Sometimes even getting something you have no idea how you did break it and would have to try a couple of times... tedious.

I just want to mention one thing about the ContentSizeFitter. This guy worked within hierarchical structures of Horizontal and Vertical Layout Groups no problem. It was the only way to build menu structures dictated from the sizes of their visual elements like buttons and images. Mathieu Muller told me once that it's fine to use them since it's just a warning they're showing when used in such a situation. Probably to avoid that users mix them with layout groups unintentionally.

Bottom line:
I think the UI has at least one major problem that's causing all these bugs. The longer you use it the more it's getting weird. And if you ever fix the system, please don't do this by not allowing setups of Horizontal- and VerticalLayoutGroups with ContentSizeFitters anymore.

I hope you find the center of all this evil. The UI worked very well about 2 years ago, but for some time, every time I tried building something simple out of it... nope, behaving like the joker, unpredictable and mean.

 

@karl_jones @Liudas @KasparasKralikas Thank you guys very much for taking your time. As it turned out, two of the cases were no bugs, just my misunderstanding of the UI, I'm sorry for that.
The two others have already been reported:
- RectTransform has values that stay greyed out
- Layout updates are not triggered immediately when adding first sibling (maybe other circumstances too)

That was darn quick, handling all 4 of the issues, awesome job.
Sorry again for the unnecessary work. I'll be more careful next time.

 

Note that "RectTransform has values that stay greyed out" has been fixed and is being backported to 18.2 as we speak (dont know when it will land but "soon")

The other is something we are looking at but nothing yet.

 

Uuuuh, does backporting mean you guys already have 2018.3 at hand?

 

Means we've already split off our main repo to have a 18.3 release branch so any changes need to be merged back to that release branch.

 

So where can other users find the clarification, so that we can avoid raising these issues again?

 

@phil-Unity @karl_jones I found yet another two bugs that look like they are caused by the same problem:

- case 1083162: VerticalLayoutGroup, HorizontalLayoutGroup, ContentSizeFitter: elements misalign when edited
- case 1083649: VerticalLayoutGroup, HorizontalLayoutGroup, ContentSizeFitter: InputField does not Extend

This really looks like one main cause that manifests ineself in these ways. Did you find out what that is through the previous ones already?

 

Having the same issue in Unity 2019.2.2

If my UI prefab has a lot of "Content Size Fitter" and "Vertical/Horizontal Layout Group" components, it tends to get all messed up soon as I try to save it or apply any changes to the prefab. What is weird though is when I save the scene, the prefab UI elements will return to the positions they are supposed to be in... It is generally the elements that have a content size fitter and are also children of objects with Layout Group components, those are the items getting messed up on runtime and when trying to save the changes to the prefab.

I've experienced this bug with previous versions of Unity as well, it's frustrating to see that it is still in 2019.2.2 - Can anyone provide any insight or possible fixes to this problem?

 

I found a workaround for this issue.

In my UI prefab, I created a script that will enable the objects that get messed up, this is my script:

Code (CSharp):

1. public class UIPrefabFix : MonoBehaviour {
2.     [SerializeField]
3.     private GameObject[] _objectsToFix;
4.  
5.     // Start is called before the first frame update
6.     void Start() {
7.         StartCoroutine(FixObjects());
8.     }
9.  
10.     private IEnumerator FixObjects() {
11.         yield return new WaitForEndOfFrame();
12.         foreach (GameObject obj in _objectsToFix) {
13.             obj.SetActive(true);
14.             yield return new WaitForEndOfFrame();
15.         }
16.     }
17. }

I put this script on my prefab, and I include all the game objects that get messed up on runtime in the _objectsToFix array, make sure these objects are DISABLED when you save your prefab, and then on runtime they will get enabled by this script and somehow that works.

Without this script, in runtime, my prefabs would get instantiated with the messed up elements, but if I was to disable/enable these elements in the editor, while the app was running, it suddenly fixes itself. So I figured this script should basically do the same thing.

 

Still getting this bug in 2020.3.11f1

Select the child of a canvas (in this case, a button)
Scale it a little bit
Press Ctrl-Z
Boom. Every other ui button with any kind of position set on them automatically centres the exact middle of the canvas.

W.T.F.