Unity Issue Tracker - [SerializeReference] Deleting an element of list with SerializeReference attribute causes an error

Won't Fix

Votes

3

Found in

2019.3.9f1

2019.4

2020.3

2021.1

2021.2

Issue ID

1237490

Regression

No

[SerializeReference] Deleting an element of list with SerializeReference attribute causes an error

Scripting

Apr 13, 2020

How to reproduce:
1. Open the attached (Repro.zip) project
2. Open the SampleScene
3. In Hierarchy Window select "Cube" GameObject
4. In Inspector Window scroll down to "Ref Vars" Script
5. Expand the variables list -> Right-click on "Vector #1" -> Delete Array Element

Expected result: No errors appear in the Console Window
Actual result: "Unsupported type Vector3f" error appears in the Console Window

Reproducible with: 2019.4.25f1, 2020.3.6f1, 2021.1.5f1, 2021.2.0a15

Notes:
- The same error also appears when pressing undo (ctrl + z) after deletion of element
- This issue does not appear if Variables are deleted starting from the bottom
- The issue cannot be tested on 2018.4 and older versions, because SerializeReference was not yet present in those versions
- Note that there are no type Vector3f in the Script, only Vector3 is present

Resolution Note (2020.2.X):

Since 2020.3, our documentation explicitly tells this case is an unsupported scenario (see https://docs.unity3d.com/2020.3/Documentation/ScriptReference/SerializeReference.html):
"- Field value cannot be a specific specialization of a generic type(inflated type)."

Comments (2)

oscarAbraham

May 24, 2021 22:29

Hi. This error has nothing to do with generics. The code behind this example doesn't use inflated generics directly; it uses concrete classes. They are not generic by any standard definition. It's not what the documentation is talking about; they don't cause the same errors as real inflated generics. Furthermore, it would happen even if the types used didn't inherit from any generic class, as long as their fields have the same name. Here's a forum post behind this issue, in case anyone wants to see the code: https://forum.unity.com/threads/serializereference-attribute.678868/page-5#post-5674003
oscarAbraham

Apr 30, 2021 18:00

Hi. This issue still exist, so it's clearly not a duplicate. An existing issue can't be a duplicate of a solved one. I'm thinking I should open another issue, in case the QA protocols are not designed to easily reconsider duplicate issues, but I'd don't want to create unwanted noise; I hope someone can look at this.

I'm pretty sure it happens when this conditions are met:
-A managed reference with a nested class/struct takes the place of another one.
-That nested class/struct is in a field with the same name but different type than another field in the managed reference that's being replaced. Example: obj1 {int val;}, obj2 {vector3 val;}.
-That change passes through the Undo system either with SerializedObject.ApplyModifiedProperties or Undo.RecordObject. RegisterCompleteObjectUndo won't trigger it.

That's why reordering in the inspector doesn't trigger this; it uses RegisterCompleteObjectUndo. Deleting array element's at the top triggers it because elements are displaced and ApplyModifiedProperties is used. Deleting at the bottom doesn't displace elements, so it's not triggered.

In case it helps, I'm not a 100% sure, but these details make me think it's related to the way the UndoPropertyModification array is built for the Undo.postprocessModifications callback.

This issue can get a lot in the way because it's not uncommon for managed reference's classes to have fields of different type but same name. Sometimes fields can just be named things "value" or "container", or sometimes two different classes derive from the same generic class. This issue doesn't seem to break anything permanently, but it can quickly fill the console with errors in some cases.

Search Issue Tracker

3