ContentSizeFitter makes scene dirty!?

I guess it is because it uses [ExecuteInEditor]?
Is there any way around this?
Is it a bug?

Note: To replicate, must change horizontal or vertical to something other then (than?) unconstrained.

 

Hey There,

Looking at the code it seems that ContentSize fitter is missing the DrivenRectTransformTracker. This class is used to stop Unity from serializing values that are driven. You could always extended the class or get the 4.6 source code and add that component.

 

After playing with it I was wrong. It does seem to have a DrivenRectTransformTracker. It's watching W Delta and H Delta.

 

Yes, it's a bug. Thanks for the bug report you submitted to our bug tracker rakkarage, we're looking into it.

 

We've identified and fixed the bug. The fix will be in one of the coming patches or releases (it didn't make it for patch 1).

 

this used to be fixed, for a while
now back in 5?
thanks

 

Using your original bug report, I can't reproduce the issue in the latest version of the codebase we have. It's possible some fixes in 4.6 patch releases didn't make it to all versions of 5.x, but the fix will make it out sooner or later anyway (if it's not out already).

 

I seem to have this behaviour on 2017.3.0f3 (64-bit)

 

Also, when you select something, sometimes, an action called "Driving RectTransform" makes the scene dirty too.

2017.3.0f3

 

Any news on this?

 

In 2018.1, the issue of "Driving RectTransform" causing Scenes to me marked as dirty upon scene-load is still (or again?) present.

 

I have the same or similar issue with 2018.2.5f1.

I'm using the content size fitter on the content within a scroll view. When I perform a build or reload the assembly, the scene is marked dirty. If the content size fitter is disabled, the scene remains untouched. The issue is likely related to the Canvas Scaler, because when I remove the Canvas Scaler, the problem seems to disappear.

Reproduction project was reported (FogBugz 1081130).

 

Experiencing the same issue under 2018.2.8f1..

It's quite annoying when Running Tests as well, because you have to go through an "Are you sure you want to close scene?" dialog every time you run the test.

 

Having the same issue in 2018.2.13. Hoping there's something I can do as a workaround as this seems to be an un-squashable bug.

 

and now in 2018.3.1f1
pretty persistent bug.. almost 5 years now :-/
it's very annoying!

 

Yes, it comes and goes all the time. I waste hours sometimes to go around this bug so my scenes don't mess my repository

 

I faintly remember, was there some kind of workaround how to prevent the ContentSizeFitter within a ScrollView from dirtying the scene?

This still bugs my team in every project. Having a ContentSizeFitter within a scroll rect is such a nice an easy setup for log displays etc, but it can get a little frustrating when the scene has to be either saved or discarded so often because people tend to lose track of whether they have actually made changes that need to be comitted or not.

Edit: My workaround was to only enable to ContentSizeFitter at runtime and have the component disabled while in edit mode.

 

If you're still seeing this issue in 2018.3.9 or later, please let us know.

 

I tested with 2018.3.9f1 today and still experienced the issue. Reproduction case 1138488.

 

Thanks for the repro. This seems unrelated to the fix in 2018.3.9 which only happens for Prefab instances. I've talked with the UI Team about how to fix this bug you reported.

As a side note it seems to already have been fixed in upcoming 2019.2 (I didn't check 2019.1), but of course the fix should be backported.

 

google search took me here.
experiencing the same issue in 2019.2.3f1. I have ContentSizeFitter in the content of a ScrollView in a prefab variant. Just opening the prefab for viewing modifies it. Also opening a scene containing an instance of the prefab makes the scene dirty.

 

The latest 2019.2 is Unity 2019.2.15. If it still happens there for you, please file a bug report. The original bug report was fixed and as such no longer reproduces.

 

I'm currently having that issue in 2019.2.14f1 on 2 different projects.
Everytime the hierarchy have intricate Layout + Fitter components it marks the scene as dirty.

I attached an example where when you open the main scene it will be marked dirty right away.

 

Can you please file it as a bug report. See
https://unity3d.com/unity/qa/bug-reporting

We don't track bugs reported via the forums.

 

I have this problem in 2019.2.3f1

 

Still available 2019.3, very annoying for Git.

 

I'm also still irritated by this issue. It keeps popping up in different forms, sometimes plain bugs, sometimes unsupported limitations of the 4.6 UI layout-components. I've been reporting issues since 2014, but it's not gotten any better. So I guess, the system is fundamentally flawed in the way it handles changes that should or should not be saved with the scene.

I guess the only thing I'm hoping for is that UIElements/UIToolkit will be an improvement and that it's ready soon...

 

For those experiencing this, a quick fix is to disable the content size fitter then activate it during onstart, so that when you are in editor, it does not change your UI.

Git is no longer a fuxmess

 

We should not need a hack for this. It's one thing to do a workaround for something that nobody is aware of or the stack is no longer supported, but the original bug was proposed almost 6 years ago and still present in 2019.3

 

Totally agree , after 6 years we still have this (pretty annoying) issue.

 

I have this problem in 2019.3.6f1

 

It is some kind of a funny joke? 2019.4.1 and the bug is still here!
@runevision

 

I reported it but they couldn't reproduce it. It feels strange to still experience it so consistently.

 

Yep me too. 2019.4.5. Through the project it was occasional, and then a second save would solve it, but now it is in a state where it never resolves itself.
I've got values in the inspectors buzzing around when its not running. The Pos Y value is buzzing up and down but always -0.000NNNNNNN

Ahh, interesting. I managed to stop this buzzing with the removal of fractions in the parent rect transforms (well until they get replaced with 1.907349e-06 instead of 0) but is still is not saving cleanly. I guess that may not be a cause but a symptom of something else.

Because of this I now cannot use a plugin that searches for references (AssetUsageDetector - a VERY useful tool) as it requires you to save the scene before it starts - and when you do, it marks it dirty, and so the tool thinks I haven't. As with others I cannot supply a repo case as it was slow to happen and I cannot upload my entire project.

Dear Unity @runevision : I know it is unreasonable to track a bug through a forum but I think at times there could be exceptions and these posts are useful to log a bug that is hard to reproduce. It is still a bug if it is not easily reproduced.

 

Is this a joke? It's been 6 years and this bug still exist. And creating a huge problem with Git while I'm trying to merge my scenes.

 

My problem has been partially fixed by almost NEVER using Content Size Fitters! In a layout group the flags I now read as "Control Child Size = Add content size fitter on all children" which I think is correct. These flags mean you don't need to add the fitter yourself and get conficts. If you don't want a particular child to have one then add a LayoutElement to it and fiddle with the settings til you get what you want (yes I still don't fully understand it all!).
When you see that warning about control conflicts you MUST solve them. That was my take away and this technique did it.

 

@Nodrap that's not how the content size fitter is even supposed to be used. You get a warning if you try to add it to children of layout components, and i'm sure the reports here are not about this misusage (atleast mine wasn't). So this is not actually a fix.

 

Sorry, wasn't clear. What I mean is the Control Child Size flag replaces using a content size fitter. When you think you need a content size fitter use the Control Child Size flag instead. Then you don't get the conflict warning. Once these warnings were gone I got my undo back and could save the scene without it marking it modified straight away

 

This issue keeps coming up since 2014, it's so frustrating. I have a very basic setup that functionally works but sets the scene dirty when exiting play mode or switching the game view around in edit mode.

ScrollRect (ScrollRect)
- Viewport
- - Content (ContentSizeFitter + Vertical Layout Group)
- - - Item 1 (LayoutElement with preferred height)
- - - Item 2 (LayoutElement with preferred height)

Why can't this be fixed and how can I work around it? I just hope UI Toolkit will get it right this time.

 

Up.
Still happening in 2020.1.13 with UI prefabs that have a content size fitter component; tbh, this is quite ridiculous, the ticket is SIX years old and somehow this is still a thing.
Having scenes constantly marked as dirty is a nightmare for version control :/

 

Up

 

I believe there are multiple reasons for the scene becoming dirty, but they all come down to the principle that multiple UI components change RectTransform properties in edit mode and tell the engine to not save these changes. My assumption is that ever since Unity fixed a couple of bugs, these components do work correctly on their own and for many use cases, but there are still a few things, where the system is fundamentally flawed on ends that can't be easily fixed. For example, two layout groups fighting against each other. Both only change their own DrivenRectTransformProperties, which wouldn't set the scene dirty on their own, e.g. both try to set the sizeDelta. For unknown reasons, in this example, it can happen that suddenly the position changes from 0 to 0.00001 and the scene is dirty, although none of the components actually modified the position directly. For some cases, Unity decided to add a warning that specific setups are not allowed although they technically work at runtime. For example, if you try using an AspectRatioFitter on the items within a ScrollRect, everything looks correct, but the warning shows, and the scene is set dirty.

I'd wish this was something that could be fixed, but seeing that the issue started when the 4.6 UI was introduced and never went away since, I doubt it's possible. Unity probably did the best thing by investing in UI Toolkit, which won't have this problem since it's decoupled from the scene.

 

That could be but in this case I just have a Canvas with a single VerticalLayout+ContentFitter element in it and it always marks the scene dirty; no weird combination or nesting, and still. :/

 

Up. Please, give us a life sign

 

My guess is that this problem is related to more deeply cascading 'dirtiness'/changes that they can only solve reliably for the first few steps, so they ignore it thinking that UIElements will solve it when it's ready and the few people that do have problems now are too little to allocate time for when it's not that easy to reproduce and it'll become obsolete sometime in the future anyway (although how knows when).

 

I'm fully aware of this, but the UIElements have been under development for years now and are still not a reliable alternative to UGUI for production.
I'm ok with dropping one as long as the other is fully operational; in the meantime, bugs like that are really annoying especially because they have been on for SIX years, long before UIElements were even announced :/

 

@runevision, sorry to tag you here but, as I see you answered on this thread before, would you maybe be able to get feedback on the issue from the unity team?

 

What feedback? We know you don't like bugs, but we still need bug reports reported through the bug reporter, with repro project and repro steps, to be able to investigate issues.

 

@runevision here's a properly made bug report, with the second-latest Unity version (2020.1.13) 1295028.
I'm sorry if I sounded a bit rude before, most of the people here do games and write software for a living and are aware of how hard and annoying it is to track back and get rid of bugs; nevertheless, sometimes there's the feeling that small things that can create a lot of problems (like this one, that can potentially create a lot of conflicts when using unity with version control in a team) just get left behind as new features start to get implemented, ending up in a situation where said new features are too unreliable for production yet, while old ones carry long-time unresolved bugs.