FIX: ISXB-1584, ISXB-1688, ISXB-1692, ISXB-1693, ISXB-1694, ISXB-1701 InputActionReference bug fixes and improved test coverage.

[ekcoh]

Description

Fixes the following issues:

• https://issuetracker.unity3d.com/product/unity/issues/guid/ISXB-1584, where InputActionReference.action would return an incorrect (cached) action if set programmatically after the cached instance had been resolved.
• ISXB-1688 - InputActionSetupExtensions.RemoveAction(action) throws exception if attempting to remove an action that doesn't have any bindings.
• ISXB-1692 - Assigning an InputActionReference field stored in an .inputactions asset via InputActionReference.Set in playmode corrupts the referenced asset.
• ISXB-1693 - InputActionReference.Create(null) returns null instead "of a reference object to the given action". If its desirable to assign a reference to null when action is null, one should not call Create to begin with.
• ISXB-1694 - InputActionReference.Set(null) does not update the cached input action reference nor the ScriptableObject.name leading to incorrect action being returned and reference showing up as the path to the previously assigned action in Inspector.
• ISXB-1699 - InputActionAsset.RemoveActionMap doesn't remove actions within the map, leaving them with stale references back to the map. This was a misinterpretation and have been reverted. Ticket marked "As Designed".
• ISXB-1701 - Inspector field of type InputActionReference isn't reflecting broken reference in case action is deleted from asset, action map is deleted from asset or the asset itself is deleted.

Revisiting/altering fixes of the previous tickets:

• ISX-1968 "Investigate InputActionReferences problem with FEPM/CoreCLR"
• https://issuetracker.unity3d.com/product/unity/issues/guid/ISXB-900 "Action Map Must Be Contained in State" and other errors are thrown when re-entering Play mode without a domain reload, while using temporarily created InputBindings. FIX: InputActionReference when using FEPM (ISX-1968) #1949

The above revisited tickets reference the problem of InputActionReference run-time objects not being reset when exiting play-mode with domain reloads disabled. To get this scenario covered, this scenario is now included in the added editor tests. Tested both with and without domain reloads enabled.

Additional changes made:

• Simplified code in InputSystemProvider.cs (UITK integration) since there is no reason to use InputActionReference in that class as long as there is no UI to edit it implemented. If such a UI is added later it can easily be converted back to InputActionReference.
• Renamed function arguments in non-public functions of InputActionReference to eliminate name-shadowing warnings. Didn't touch public ones since a parameter rename would be unexpected after API publishing.
• Simplified loading code of InputActionReference instances from assets within InputActionImporter.
• Adds EditorPrefsTestUtils.cs which is a test utility to simplify editor tests.
• Adds CoreTests_Actions_References.cs which extracts previous and new InputActionReference play-mode tests into their own (partial) file.
• Adds DumpInputActionReferences.cs which extends "QA Tools" with ability to dump a list of all input action references (loaded + assets) into the console via QA Tools Unity menu.

Open issues/questions to reviewers:

• Property drawer for input action references is currently conditionally compiled depending on project-wide input actions. This makes little sense now, but if the check is removed we get a dependency on search context that isn't available in that version, so we might want to land this post 2021.3 EoL or add a similar fix for 2021.3? (Currently missing on PR)

Testing status & QA

Added a bunch of functional tests that replicates the problematic scenarios mentioned above. Both play-mode functional tests as well as edit-mode as well as transitional editor-mode to play-mode and play-mode to edit-mode editor tests were added.

Removed some code related to project-wide-actions in property drawer I believe @jfreire-unity added. I do not think it is needed as a special case anymore and I also think it was incorrect to change the users objects.

Altered a previous play-mode fix by @timkeo but it is essentially intact to previous behavior. I think there is opportunity to change this later to only use Object.FindObjectsByType(true) instead of Resources.FindObjectsByType() as an optimisation after this has landed?

Haven''t tested on 2021.3 which might be behaving differently but I do not know if we should bother since it is soon EoL.

Overall Product Risks

• Complexity: Medium
• Halo Effect: Large

InputActionReferences are used all over the place so this is a serious bug that can have impact, especially on more complex projects.

Comments to reviewers

Recommend double checking the repro project with this fix.

Checklist

Before review:

• Changelog entry added.
  • Explains the change in Changed, Fixed, Added sections.
  • For API change contains an example snippet and/or migration example.
  • JIRA ticket linked, example (case %%). If it is a private issue, just add the case ID without a link.
  • Jira port for the next release set as "Resolved".
• Tests added/changed, if applicable.
  • Functional tests added: Actions_CanResolveActionReferenceAndThenSetItToAnotherAction
  • Performance tests. - None
  • Integration tests. - None
• Docs for new/changed API's.
  • Xmldoc cross references are set correctly.
  • Added explanation how the API works.
  • Usage code examples added.
  • The manual is updated, if needed.

During merge:

• Commit message for squash-merge is prefixed with one of the list:
  • NEW: ___.
  • FIX: ___.
  • DOCS: ___.
  • CHANGE: ___.
  • RELEASE: 1.1.0-preview.3.

After merge:

• Create forward/backward port if needed. If you are blocked from creating a forward port now please add a task to ISX-1444.

[codecov-github-com]

Codecov Report

Attention: Patch coverage is 89.00634% with 52 lines in your changes missing coverage. Please review.

Files with missing lines	Patch %	Lines
Assets/Tests/InputSystem.Editor/TestUtils.cs	17.07%	34 Missing ⚠️
...System/Editor/AssetImporter/InputActionImporter.cs	81.48%	5 Missing ⚠️
...pertyDrawers/InputActionReferencePropertyDrawer.cs	68.75%	5 Missing ⚠️
...s/Tests/InputSystem.Editor/EditorPrefsTestUtils.cs	85.71%	3 Missing ⚠️
...system/InputSystem/Actions/InputActionReference.cs	93.33%	3 Missing ⚠️
...utSystem.Editor/InputActionReferenceEditorTests.cs	97.61%	2 Missing ⚠️

@@ Coverage Diff @@ ## develop #2248 +/- ## =========================================== + Coverage 76.70% 76.77% +0.06%  =========================================== Files 465 476 +11 Lines 87919 88629 +710 =========================================== + Hits 67442 68048 +606  - Misses 20477 20581 +104 

Flag	Coverage Δ
inputsystem_MacOS_2021.3	5.93% <18.07%> (+0.02%)	⬆️
inputsystem_MacOS_2022.3	5.39% <16.85%> (+0.02%)	⬆️
inputsystem_MacOS_2022.3_project	74.68% <88.46%> (+0.09%)	⬆️
inputsystem_MacOS_6000.0	5.18% <0.00%> (-0.01%)	⬇️
inputsystem_MacOS_6000.0_project	76.57% <88.98%> (+0.06%)	⬆️
inputsystem_MacOS_6000.2	5.18% <0.00%> (-0.01%)	⬇️
inputsystem_MacOS_6000.2_project	76.57% <88.98%> (+0.06%)	⬆️
inputsystem_MacOS_6000.3	5.18% <0.00%> (-0.01%)	⬇️
inputsystem_MacOS_6000.3_project	76.57% <88.98%> (+0.06%)	⬆️
inputsystem_MacOS_6000.4	5.18% <0.00%> (-0.01%)	⬇️
inputsystem_MacOS_6000.4_project	76.57% <88.98%> (+0.06%)	⬆️
inputsystem_Ubuntu_2021.3	5.94% <18.07%> (+0.02%)	⬆️
inputsystem_Ubuntu_2022.3	5.40% <16.85%> (+0.02%)	⬆️
inputsystem_Ubuntu_2022.3_project	74.47% <88.46%> (+0.08%)	⬆️
inputsystem_Ubuntu_6000.0	5.19% <0.00%> (-0.01%)	⬇️
inputsystem_Ubuntu_6000.0_project	76.37% <88.98%> (+0.05%)	⬆️
inputsystem_Ubuntu_6000.2	5.19% <0.00%> (-0.01%)	⬇️
inputsystem_Ubuntu_6000.2_project	76.37% <88.98%> (+0.05%)	⬆️
inputsystem_Ubuntu_6000.3	5.19% <0.00%> (-0.01%)	⬇️
inputsystem_Ubuntu_6000.3_project	76.38% <88.98%> (+0.06%)	⬆️
inputsystem_Ubuntu_6000.4	5.19% <0.00%> (-0.01%)	⬇️
inputsystem_Ubuntu_6000.4_project	76.37% <88.98%> (+0.05%)	⬆️
inputsystem_Windows_2021.3	5.93% <18.07%> (+0.02%)	⬆️
inputsystem_Windows_2022.3	5.39% <16.85%> (+0.02%)	⬆️
inputsystem_Windows_2022.3_project	74.80% <88.46%> (+0.07%)	⬆️
inputsystem_Windows_6000.0	5.18% <0.00%> (-0.01%)	⬇️
inputsystem_Windows_6000.0_project	76.70% <88.98%> (+0.05%)	⬆️
inputsystem_Windows_6000.2	5.18% <0.00%> (-0.01%)	⬇️
inputsystem_Windows_6000.2_project	76.70% <88.98%> (+0.05%)	⬆️
inputsystem_Windows_6000.3	5.18% <0.00%> (-0.01%)	⬇️
inputsystem_Windows_6000.3_project	76.70% <88.98%> (+0.05%)	⬆️
inputsystem_Windows_6000.4	5.18% <0.00%> (-0.01%)	⬇️
inputsystem_Windows_6000.4_project	76.70% <88.98%> (+0.05%)	⬆️

Flags with carried forward coverage won't be shown. Click here to find out more.

Files with missing lines	Coverage Δ
...r/InputActionReferencePropertyDrawerEditorTests.cs	100.00% <100.00%> (ø)
Assets/Tests/InputSystem/CoreTests_Actions.cs	97.77% <100.00%> (-0.01%)	⬇️
...s/Tests/InputSystem/CoreTests_Actions_Reference.cs	100.00% <100.00%> (ø)
.../InputSystem/Actions/InputActionSetupExtensions.cs	79.09% <100.00%> (ø)
...s/com.unity.inputsystem/InputSystem/InputSystem.cs	83.57% <100.00%> (+0.52%)	⬆️
...utSystem/Plugins/InputForUI/InputSystemProvider.cs	86.60% <100.00%> (-0.37%)	⬇️
...utSystem.Editor/InputActionReferenceEditorTests.cs	97.61% <97.61%> (ø)
...s/Tests/InputSystem.Editor/EditorPrefsTestUtils.cs	85.71% <85.71%> (ø)
...system/InputSystem/Actions/InputActionReference.cs	90.10% <93.33%> (+30.85%)	⬆️
...System/Editor/AssetImporter/InputActionImporter.cs	57.65% <81.48%> (+7.89%)	⬆️
... and 2 more

... and 16 files with indirect coverage changes

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[ekcoh]

This solves the incorrect return value, but it seems it is not enough to solve the reported problem so moving this back to draft mode for more work.

[ekcoh]

@jfreire-unity @Pauliusd01 I think I have eliminated the warnings on this branch now. The two key warnings must be present on develop and should be fixed separately. While fixing I realised the associated code could be simplified.

[ekcoh]

I guess we should investigate if we can have an automated test that could fail if any warning is generated that maps to our assemblies.

[jfreire-unity]

Sorry to take so long to review.

1. I'm not able to fix the main issue (ISXB-1584) as it now raises an error. I also don't understand what should I do based on the exception logged message.

2. Does this mean that InputActionReference.Set() cannot be run at in Play-mode now?

3. There's no guidance in the PR description to make the main bug work be fixed with this change. That could have been helpful.

4. I'm much longer to review because there are a lot of things we're fixing in this PR and I'm not familiar with the impact of all the changes.

The only think I have to point out is that to me is that the changes raising an error for ISXB-1584 are a relatively impactfull breaking change, unless I'm seeing this wrong.
If I'm indeed correct, then let's just make this a bit more explicit and add maybe one example in a Discussions post or something. Happy to chat about it.

[jfreire-unity]

This is the message I get when opening the ISXB-1584 project in 6.2.0f1 and using the package in this branch:

InvalidOperationException: Attempting to mutate an immutable InputActionReference instance. This is not allowed since it would modify the source asset.Instead use InputActionReference.Create(action) to create a new in-memory instance or serialize it as a separate asset if it survive domain reloads. 

[ekcoh]

This is the message I get when opening the ISXB-1584 project in 6.2.0f1 and using the package in this branch:

InvalidOperationException: Attempting to mutate an immutable InputActionReference instance. This is not allowed since it would modify the source asset.Instead use InputActionReference.Create(action) to create a new in-memory instance or serialize it as a separate asset if it survive domain reloads. 

Could you elaborate a bit more on the reproduction steps? Just opening the repo root without doing anything?

[jfreire-unity]

This is the message I get when opening the ISXB-1584 project in 6.2.0f1 and using the package in this branch:

InvalidOperationException: Attempting to mutate an immutable InputActionReference instance. This is not allowed since it would modify the source asset.Instead use InputActionReference.Create(action) to create a new in-memory instance or serialize it as a separate asset if it survive domain reloads. 

Could you elaborate a bit more on the reproduction steps? Just opening the repo root without doing anything?

I downloaded the "bug project", used this PR branch, and got that error when entering playmode. I'll test a 3rd time now from scratch

[ekcoh]

This is the message I get when opening the ISXB-1584 project in 6.2.0f1 and using the package in this branch:

InvalidOperationException: Attempting to mutate an immutable InputActionReference instance. This is not allowed since it would modify the source asset.Instead use InputActionReference.Create(action) to create a new in-memory instance or serialize it as a separate asset if it survive domain reloads. 

Could you elaborate a bit more on the reproduction steps? Just opening the repo root without doing anything?

I downloaded the "bug project", used this PR branch, and got that error when entering playmode. I'll test a 3rd time now from scratch

I now I understand, sorry, Friday-slowness, yes, the repro scenario cannot be allowed. It corrupts the assets. Try the original one if you are curious and see that after exiting playmode, asset A is containing a reference to a sub-asset in asset B......

[ekcoh]

This is the message I get when opening the ISXB-1584 project in 6.2.0f1 and using the package in this branch:

InvalidOperationException: Attempting to mutate an immutable InputActionReference instance. This is not allowed since it would modify the source asset.Instead use InputActionReference.Create(action) to create a new in-memory instance or serialize it as a separate asset if it survive domain reloads. 

Could you elaborate a bit more on the reproduction steps? Just opening the repo root without doing anything?

I downloaded the "bug project", used this PR branch, and got that error when entering playmode. I'll test a 3rd time now from scratch

I now I understand, sorry, Friday-slowness, yes, the repro scenario cannot be allowed. It corrupts the assets. Try the original one if you are curious and see that after exiting playmode, asset A is containing a reference to a sub-asset in asset B......

I haven't replied to user yet, but the recommendation will be to instead.

reference = InputActionReference.Create(desiredAction);

[jfreire-unity]

InputActionReference.Create(desiredAction);

Got it. It works, thanks. For some reasons it didn't work before (maybe I had the project with asset already changed by using .Set() without these changes)

[jfreire-unity]

I'm approving now that I managed to solve the customer issue. Good work.

This is a small change in behavior so I think we should communicate this somehow in a Discussions post. I can already predict more bugs related to this change.

[ekcoh]

InputActionReference.Create(desiredAction);

Got it. It works, thanks. For some reasons it didn't work before (maybe I had the project with asset already changed by using .Set() without these changes)

Awesome, yeah I found that if you enter playmode once with the repro project you have corrupted the asset beyond what can be resolved by reimport or action editor changes.

[ekcoh]

I'm approving now that I managed to solve the customer issue. Good work.

This is a small change in behavior so I think we should communicate this somehow in a Discussions post. I can already predict more bugs related to this since.

Would probably make sense to provide an example with the release post. Regardless, the existing behaviour is clearly faulty so at least IMO this improves things and leads to less suprises with corrupt assets or cross-asset references.

[ekcoh]

Hmmm..... maybe this still causes errors on 2021.3 since that version wouldn't have PWA define

[ekcoh]

Hmmm..... maybe this still causes errors on 2021.3 since that version wouldn't have PWA define

Confirmed, property drawer is mutating reference via serialised property when used on Unity versions where PWA isn't supported (rather SearchProvider isn't supported), a custom property drawer is also needed before that to not corrupt assets. Will add an update to this PR.

[ekcoh]

Hmmm..... maybe this still causes errors on 2021.3 since that version wouldn't have PWA define

Confirmed, property drawer is mutating reference via serialised property when used on Unity versions where PWA isn't supported (rather SearchProvider isn't supported), a custom property drawer is also needed before that to not corrupt assets. Will add an update to this PR.

Addressed in 9c7cb44

[jfreire-unity]

@ekcoh as a sanity check, I would check with packages like XR and Cinemachine if they have any immediate problems with this change.

[ekcoh]

@ekcoh as a sanity check, I would check with packages like XR and Cinemachine if they have any immediate problems with this change.

Good idea. I am have reached out in appropriate internal channels to see if additional feedback can be collected.

[ekcoh]

According to @windxu88 the Ubuntu instability is expected in CI at the moment

[Pauliusd01]

Been looking at this on and off for a while and it seems fine so far. Still looking into it but got minor notes:

• Some minor improvements for the error you get when trying to use InputActionReference.Set() "InvalidOperationException: Attempting to mutate an immutable InputActionReference instance. This is not allowed since it would modify the source asset.Instead use InputActionReference.Create(action) to create a new in-memory instance or serialize it as a separate asset if **it survive domain reloads**." I assume the ending was supposed to be something like "...if it to survive domain reloads" or even expanding the sentence further.
• For ISXB-1688 is it about creating and modifying asset files in editor? As I didn't have any problems removing actions in runtime before or after your changes.
• For ISXB-1692 how is it different from ISXB-1584? Just a bit of extra info would help as to me it just seemed the same.

[ekcoh]

@ekcoh as a sanity check, I would check with packages like XR and Cinemachine if they have any immediate problems with this change.

Cinemachine team confirmed it doesn't seem to cause any issues with Cinemachine.

[ekcoh]

Been looking at this on and off for a while and it seems fine so far. Still looking into it but got minor notes:

• Some minor improvements for the error you get when trying to use InputActionReference.Set() "InvalidOperationException: Attempting to mutate an immutable InputActionReference instance. This is not allowed since it would modify the source asset.Instead use InputActionReference.Create(action) to create a new in-memory instance or serialize it as a separate asset if **it survive domain reloads**." I assume the ending was supposed to be something like "...if it to survive domain reloads" or even expanding the sentence further.

Thanks for the feedback. I look into making that exception message better.

• For ISXB-1688 is it about creating and modifying asset files in editor? As I didn't have any problems removing actions in runtime before or after your changes.

No, it's about doing it programmatically and I have covered it with an automated test that failed when implemented. Then fixed the issue.

• For ISXB-1692 how is it different from ISXB-1584? Just a bit of extra info would help as to me it just seemed the same.

It's not fundamentally different, but I decided to see ISXB-1584 as the reported problem, that the action wasn't properly updated. This particular one is about corrupting it. There was many things happening at once in 1584 and I just filed specific tickets per problem. This one refers to the part that if you run the repro project without these changes after exiting playmode the first asset (originally containing A), will contain a reference pointing to an action within the asset containing B.