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".
• 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.