-
Notifications
You must be signed in to change notification settings - Fork 328
FIX: ISXB-1674 - Input actions asset not converted correctly when upgrading from 1.14.1 (Regression) #2244
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: develop
Are you sure you want to change the base?
FIX: ISXB-1674 - Input actions asset not converted correctly when upgrading from 1.14.1 (Regression) #2244
Conversation
I noticed this PR title was incorrect so I changed it to remove that failure. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for looking into this, my main comment at this review round is to add inline comments explaining why we need to do the different parts since it is not clear to me from the code. I think this is important to make sure its maintainable.
Packages/com.unity.inputsystem/InputSystem/Actions/InputActionAsset.cs
Outdated
Show resolved
Hide resolved
if (mapJson.actions == null || mapJson.actions.Length == 0) | ||
continue; | ||
|
||
for (var ai = 0; ai < mapJson.actions.Length; ++ai) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It looks like 'ai' isn't really used so why not e.g foreach instead?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
the iterator actionJson
is immutable as the ReadActionJson is a struct so we use for loop instead of foreach.
Packages/com.unity.inputsystem/InputSystem/Actions/InputActionAsset.cs
Outdated
Show resolved
Hide resolved
if (tokens.Count == 0) | ||
continue; | ||
|
||
var parsed = new List<NameAndParameters>(tokens.Count); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Also this list may be moved to outer scope to avoid allocating on every iteration.
foreach (var t in tokens) | ||
parsed.Add(NameAndParameters.Parse(t)); | ||
|
||
var rebuiltTokens = new List<string>(tokens.Count); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
same with this list
Packages/com.unity.inputsystem/InputSystem/Actions/InputActionAsset.cs
Outdated
Show resolved
Hide resolved
Packages/com.unity.inputsystem/InputSystem/Actions/InputActionAsset.cs
Outdated
Show resolved
Hide resolved
Packages/com.unity.inputsystem/InputSystem/Actions/InputActionAsset.cs
Outdated
Show resolved
Hide resolved
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There are a few things you mention in the PR description that I don't understand why they are needed:
Preserve original tokens and only touch the enum values
Formatting survive unchanged
I don't understand why this would be a requirement, I believe that if the user uses our editor to edit the asset that was written manually and has custom formatting that will overwrite the users formatting. Trying to parse json with string replaces, regex is a losing battle, the only way this won't be brittle is by parsing it, converting the data and serializing it back to json.
Avoid whole string rewrites, which previously caused mismatches between what the editor expected
As above, I don't understand why do we want to avoid string rewrites, my current thinking is that we didnt catch this for 2 reasons, we are not reusing the parsing and serializing funcitons that is used elsewhere, and we didnt test this case.
I believe the proper way of moving forward here is that we use the exact same code to parse and serialize json for this type that is used elsewhere in the editor, if we try to do anything different we are creating an opportunity for a bug to be hidden here.
Packages/com.unity.inputsystem/InputSystem/Actions/InputActionAsset.cs
Outdated
Show resolved
Hide resolved
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Same comment as @LeoUnity, let's complement the test by making sure it parses correctly (logically) and then we can conclude this I believe.
Packages/com.unity.inputsystem/InputSystem/Utilities/NameAndParameters.cs
Show resolved
Hide resolved
Packages/com.unity.inputsystem/InputSystem/Actions/InputActionAsset.cs
Outdated
Show resolved
Hide resolved
|
||
internal static NameAndParameters Create(string name, IList<NamedValue> parameters) | ||
{ | ||
var result = new NameAndParameters |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nitpick: Why create a result variable here instead of just
return new NameAndParameters { .... };
m_ListProperty.serializedObject.ApplyModifiedProperties(); | ||
} | ||
|
||
private static string ToSerializableString(IEnumerable<NameAndParameters> parametersForEachListItem) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why is this function existing if it only forwards to NameAndParameters.SerializeMultiple? Seems redundant
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Maybe keep the old name instead?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Missing an automated test case that reproduces the issue we are trying to fix here.
yield return null; | ||
} | ||
|
||
[Test] |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We are missing a test case here that tests that an action map containing 2 processors are working. It's the whole reason we are doing this fix. We know that with a single processor everything was working.
… ListView is editor only.
[Test] | ||
public void Migration_ShouldProduceValidActionAsset_WithAllProcessors_AndEnumConverted() | ||
{ | ||
m_ActionMap.ResolveBindings(); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This test passes without the fix, this means this is not testing what we want. The asset in the editor is created with version 1 already, the migration code is not being run at all as part of this test.
There are 2 problems with the way we create the asset:
- The asset is created once and shared across the different tests, which means the order in which the tests run could impact the results of the test, this is bad.
- The migration code requires the version to be 0, creating the asset via the editor will create an asset with version 1.
Also the start data already has the CustomProcessor with the value being 10, the initial value should be 1, and then the conversion should run and upgrade it to 10.
This test is not a UI test, but its part of the UIToolkitBaseTestWindow class, I would recommend splitting this test into its own class that has no dependency on the UI.
Description
Bug: https://jira.unity3d.com/browse/ISXB-1674
Port: 1.14.X
Preserve original tokens and only touch the enum values. That means processor names, order, legacy processors, and formatting survive unchanged so the editor no longer collapses or marks them “Obsolete”.
Avoid whole string rewrites, which previously caused mismatches between what the editor expected and what was written back and only assign a new processor string if something actually changed.
Testing status & QA
Verified manually with the attached repro project.
Overall Product Risks
Complexity: 0
Halo Effect: 0
Comments to reviewers
Checklist
Before review:
Changed
,Fixed
,Added
sections.Area_CanDoX
,Area_CanDoX_EvenIfYIsTheCase
,Area_WhenIDoX_AndYHappens_ThisIsTheResult
.During merge:
NEW: ___
.FIX: ___
.DOCS: ___
.CHANGE: ___
.RELEASE: 1.1.0-preview.3
.After merge: