CHANGE: UI module now defaults to having DefaultInputActions (case 1359306, #1397).

Author: Rene Damm

Assets/Tests/InputSystem/CoreTests_Actions.cs

@@ -1536,21 +1536,41 @@ public void Actions_ResettingDevice_CancelsOngoingActionsThatAreDrivenByIt()
         // Create an action that performs on button *up*. This way we can tell whether
         // the action is truly cancelled or whether it simply gets triggered by us
         // resetting the corresponding device state.
-        var buttonReleaseAction = new InputAction(type: InputActionType.Button, binding: "<Gamepad>/buttonSouth",
+        var buttonReleaseAction = new InputAction(name: "button", type: InputActionType.Button, binding: "<Gamepad>/buttonSouth",
             interactions: "press(behavior=1)");
         buttonReleaseAction.Enable();
 
+        var valueAction = new InputAction(name: "value", type: InputActionType.Value, binding: "<Gamepad>/buttonSouth");
+        valueAction.Enable();
+
+        var passThroughAction = new InputAction(name: "passthrough", type: InputActionType.PassThrough, binding: "<Gamepad>/buttonSouth");
+        passThroughAction.Enable();
+
         Press(gamepad.buttonSouth);
 
         Assert.That(buttonReleaseAction.phase, Is.EqualTo(InputActionPhase.Started));
         Assert.That(buttonReleaseAction.activeControl, Is.SameAs(gamepad.buttonSouth));
 
+        Assert.That(valueAction.phase, Is.EqualTo(InputActionPhase.Started)); // Goes back to Started after Performed.
+        Assert.That(valueAction.activeControl, Is.SameAs(gamepad.buttonSouth));
+
+        Assert.That(passThroughAction.phase, Is.EqualTo(InputActionPhase.Performed));
+        Assert.That(passThroughAction.activeControl, Is.SameAs(gamepad.buttonSouth));
+
         using (var buttonReleaseActionTrace = new InputActionTrace(buttonReleaseAction))
+        using (var valueActionTrace = new InputActionTrace(valueAction))
+        using (var passThroughActionTrace = new InputActionTrace(passThroughAction))
         {
             InputSystem.ResetDevice(gamepad);
 
-            Assert.That(buttonReleaseActionTrace,
-                Canceled(buttonReleaseAction));
+            Assert.That(buttonReleaseActionTrace, Canceled(buttonReleaseAction));
+            Assert.That(valueActionTrace, Canceled(valueAction));
+
+            // This case is quirky. For button and value actions, the reset of the control value
+            // does not cause the action to start back up. For pass-through actions, that is different
+            // as *any* value change performs the action. So here, we see *both* a cancellation and then
+            // immediately a performing of the action.
+            Assert.That(passThroughActionTrace, Canceled(passThroughAction).AndThen(Performed(passThroughAction, value: 0f)));
         }
     }
 

Assets/Tests/InputSystem/Plugins/UITests.cs

@@ -109,6 +109,7 @@ private static TestObjects CreateTestUI(Rect viewport = default, bool noFirstSel
         var systemObject = new GameObject(namePrefix + "System");
         objects.eventSystem = systemObject.AddComponent<TestEventSystem>();
         var uiModule = systemObject.AddComponent<InputSystemUIInputModule>();
+        uiModule.UnassignActions();
         objects.uiModule = uiModule;
         objects.eventSystem.UpdateModules();
 
@@ -182,6 +183,40 @@ private static TestObjects CreateTestUI(Rect viewport = default, bool noFirstSel
         return objects;
     }
 
+    [Test]
+    [Category("UI")]
+    public void UI_InputModuleHasDefaultActions()
+    {
+        var go = new GameObject();
+        var uiModule = go.AddComponent<InputSystemUIInputModule>();
+
+        Assert.That(uiModule.actionsAsset, Is.Not.Null);
+        Assert.That(uiModule.point?.action, Is.SameAs(uiModule.actionsAsset["UI/Point"]));
+        Assert.That(uiModule.leftClick?.action, Is.SameAs(uiModule.actionsAsset["UI/Click"]));
+        Assert.That(uiModule.rightClick?.action, Is.SameAs(uiModule.actionsAsset["UI/RightClick"]));
+        Assert.That(uiModule.middleClick?.action, Is.SameAs(uiModule.actionsAsset["UI/MiddleClick"]));
+        Assert.That(uiModule.scrollWheel?.action, Is.SameAs(uiModule.actionsAsset["UI/ScrollWheel"]));
+        Assert.That(uiModule.submit?.action, Is.SameAs(uiModule.actionsAsset["UI/Submit"]));
+        Assert.That(uiModule.cancel?.action, Is.SameAs(uiModule.actionsAsset["UI/Cancel"]));
+        Assert.That(uiModule.move?.action, Is.SameAs(uiModule.actionsAsset["UI/Navigate"]));
+        Assert.That(uiModule.trackedDeviceOrientation?.action, Is.SameAs(uiModule.actionsAsset["UI/TrackedDeviceOrientation"]));
+        Assert.That(uiModule.trackedDevicePosition?.action, Is.SameAs(uiModule.actionsAsset["UI/TrackedDevicePosition"]));
+
+        uiModule.UnassignActions();
+
+        Assert.That(uiModule.actionsAsset, Is.Null);
+        Assert.That(uiModule.point, Is.Null);
+        Assert.That(uiModule.leftClick, Is.Null);
+        Assert.That(uiModule.rightClick, Is.Null);
+        Assert.That(uiModule.middleClick, Is.Null);
+        Assert.That(uiModule.scrollWheel, Is.Null);
+        Assert.That(uiModule.submit, Is.Null);
+        Assert.That(uiModule.cancel, Is.Null);
+        Assert.That(uiModule.move, Is.Null);
+        Assert.That(uiModule.trackedDeviceOrientation, Is.Null);
+        Assert.That(uiModule.trackedDevicePosition, Is.Null);
+    }
+
     // Comprehensive test for general pointer input behaviors.
     // NOTE: The behavior we test for here is slightly *DIFFERENT* than what you get with StandaloneInputModule. The reason is that
     //       StandaloneInputModule has both lots of inconsistencies between touch and mouse input (example: touch press handling goes
@@ -3371,8 +3406,8 @@ public IEnumerator UI_WhenAppLosesAndRegainsFocus_WhileUIButtonIsPressed_UIButto
 
         Assert.That(scene.actions.UI.Click.phase.IsInProgress(), Is.True);
 
-        var clickWasCanceled = false;
-        scene.actions.UI.Click.canceled += _ => clickWasCanceled = true;
+        var clickCanceled = 0;
+        scene.actions.UI.Click.canceled += _ => ++ clickCanceled;
 
         yield return null;
 
@@ -3391,7 +3426,7 @@ public IEnumerator UI_WhenAppLosesAndRegainsFocus_WhileUIButtonIsPressed_UIButto
         scene.leftChildReceiver.events.Clear();
 
         runtime.PlayerFocusLost();
-        Assert.That(clickWasCanceled, Is.True);
+        Assert.That(clickCanceled, Is.EqualTo(1));
         scene.eventSystem.SendMessage("OnApplicationFocus", false);
 
         Assert.That(scene.leftChildReceiver.events, Is.Empty);

Packages/com.unity.inputsystem/CHANGELOG.md

@@ -16,10 +16,26 @@ however, it has to be formatted properly to pass verification tests.
   * This caused a regression with some setups that, for example, bound the same control multiple times in a composite using processors to alter the value of the control.
   * Internally, a control is now again allowed to feed into the same action through more than one binding.
   * However, externally the control will be mentioned on the action's `InputAction.controls` list only once.
+- Adding `InputSystemUIInputModule` from code now installs `DefaultInputActions`. This is equivalent to the default setup when adding the component in the editor ([case 1259306](https://issuetracker.unity3d.com/issues/input-system-ugui-button-does-not-react-when-clicked)).
+  ```CSharp
+  var go = new GameObject();
+  go.AddComponent<EventSystem>();
+  var uiModule = go.AddComponent<InputSystemUIInputModule>();
+  // uiModule.actionsAsset now has a DefaultInputActions() asset assigned to it and the various
+  // action references point to its actions.
+  ```
+  * `InputSystemUIInputModule.UnassignActions` has been added to remove all actions from the module en bloc.
+  ```CSharp
+  uiModule.UnassignActions();
+  ```
 
 ### Fixed
 
 - Fixed an issue where mixing test cases based on `InputTestFixture` (using mocked `InputSystem`) and regular test cases (using real `InputSystem`) would lead to static state leaking between test cases causing random failures and unexpected/undefined behavior ([case 1329015](https://issuetracker.unity3d.com/product/unity/issues/guid/1329015)).
+- Fixed `InputSystemUIInputModule.AssignDefaultActions` not assigning `trackedDeviceOrientation` and `trackedDevicePosition`.
+- Fixed regression introduced by [previous change](#ui_multiple_scenes_fix) where `InputSystemUIInputModule` would not disable actions correctly.
+- Fixed `InputAction.canceled` not getting triggered reliably for `InputActionType.PassThrough` actions when `InputSystem.ResetDevice` was called.
+- Fixed device resets (e.g. happening as part of focus changes) leading to only some actions bound to these devices getting cancelled instead of all of them.
 
 ## [1.1.0-pre.6] - 2021-08-23
 
@@ -185,7 +201,7 @@ however, it has to be formatted properly to pass verification tests.
 - Fixed `AxisDeadzoneProcessor` min/max values not being settable to 0 in editor UI ([case 1293744](https://issuetracker.unity3d.com/issues/input-system-input-system-axis-deadzone-minimum-value-fallsback-to-default-value-if-its-set-to-0)).
 - Fixed blurry icons in input debugger, asset editor, input settings ([case 1299595](https://issuetracker.unity3d.com/issues/inputsystem-supported-device-list-dropdown-icons-present-under-project-settings-are-not-user-friendly)).
 - Fixed `clickCount` not being incremented correctly by `InputSystemUIInputModule` for successive mouse clicks ([case 1317239](https://issuetracker.unity3d.com/issues/eventdata-dot-clickcount-doesnt-increase-when-clicking-repeatedly-in-the-new-input-system)).
-- Fixed UI not working after additively loading scenes with additional InputSystemUIInputModule modules ([case 1251720](https://issuetracker.unity3d.com/issues/input-system-buttons-cannot-be-pressed-after-additively-loading-scenes-with-additional-event-systems)).
+- <a name="ui_multiple_scenes_fix"></a>Fixed UI not working after additively loading scenes with additional InputSystemUIInputModule modules ([case 1251720](https://issuetracker.unity3d.com/issues/input-system-buttons-cannot-be-pressed-after-additively-loading-scenes-with-additional-event-systems)).
 - Fixed no `OnPointerExit` received when changing UI state without moving pointer ([case 1232705](https://issuetracker.unity3d.com/issues/input-system-onpointerexit-is-not-triggered-when-a-ui-element-interrupts-a-mouse-hover)).
 - Fixed reference to `.inputactions` of `Player Prefab` referenced by `PlayerInputManager` being destroyed on going into play mode, if the player prefab was a nested prefab ([case 1319756](https://issuetracker.unity3d.com/issues/playerinput-component-loses-its-reference-to-an-inputactionasset)).
 - Fixed "Scheme Name" label clipped in "Add Control Schema" popup window ([case 1199560]https://issuetracker.unity3d.com/issues/themes-input-system-scheme-name-is-clipped-in-add-control-schema-window-with-inter-default-font)).

Packages/com.unity.inputsystem/InputSystem/Actions/InputActionPhase.cs

@@ -7,7 +7,7 @@
 namespace UnityEngine.InputSystem
 {
     /// <summary>
-    /// Trigger phase of an <see cref="InputAction">action</see>.
+    /// Trigger phase of an <see cref="InputAction"/>.
     /// </summary>
     /// <remarks>
     /// Actions can be triggered in steps. For example, a <see cref="SlowTapInteraction">
@@ -17,6 +17,11 @@ namespace UnityEngine.InputSystem
     /// the button is release before the timer expires, the action will be <see cref="Canceled"/>
     /// whereas if the button is held long enough, the action will be <see cref="Performed"/>.
     /// </remarks>
+    /// <seealso cref="InputAction.phase"/>
+    /// <seealso cref="InputAction.CallbackContext.phase"/>
+    /// <seealso cref="InputAction.started"/>
+    /// <seealso cref="InputAction.performed"/>
+    /// <seealso cref="InputAction.canceled"/>
     public enum InputActionPhase
     {
         /// <summary>
@@ -26,18 +31,16 @@ public enum InputActionPhase
 
         /// <summary>
         /// The action is enabled and waiting for input on its associated controls.
-        /// </summary>
-        /// <remarks>
+        ///
         /// This is the phase that an action goes back to once it has been <see cref="Performed"/>
         /// or <see cref="Canceled"/>.
-        /// </remarks>
+        /// </summary>
         Waiting,
 
         /// <summary>
         /// An associated control has been actuated such that it may lead to the action
-        /// being triggered.
-        /// </summary>
-        /// <remarks>
+        /// being triggered. Will lead to <see cref="InputAction.started"/> getting called.
+        ///
         /// This phase will only be invoked if there are interactions on the respective control
         /// binding. Without any interactions, an action will go straight from <see cref="Waiting"/>
         /// into <see cref="Performed"/> and back into <see cref="Waiting"/> whenever an associated
@@ -53,7 +56,7 @@ public enum InputActionPhase
         ///
         /// <see cref="Started"/> can be useful for UI feedback. For example, in a game where the weapon can be charged,
         /// UI feedback can be initiated when the action is <see cref="Started"/>.
-        /// </remarks>
+        ///
         /// <example>
         /// <code>
         /// fireAction.started +=
@@ -78,18 +81,55 @@ public enum InputActionPhase
         ///     }
         /// </code>
         /// </example>
+        ///
+        /// By default, an action is started as soon as a control moves away from its default value. This is
+        /// the case for both <see cref="InputActionType.Button"/> actions (which, however, does not yet have to mean
+        /// that the button press threshold has been reached; see <see cref="InputSettings.defaultButtonPressPoint"/>)
+        /// and <see cref="InputActionType.Value"/> actions. <see cref="InputActionType.PassThrough"/> does not use
+        /// the <c>Started</c> phase and instead goes straight to <see cref="Performed"/>.
+        ///
+        /// For <see cref="InputActionType.Value"/> actions, <c>Started</c> will immediately be followed by <see cref="Performed"/>.
+        ///
+        /// Note that interactions (see <see cref="IInputInteraction"/>) can alter how an action does or does not progress through
+        /// the phases.
+        /// </summary>
         Started,
 
         /// <summary>
+        /// The action has been performed. Leads to <see cref="InputAction.performed"/> getting called.
         ///
+        /// By default, a <see cref="InputActionType.Button"/> action performs when a control crosses the button
+        /// press threshold (see <see cref="InputSettings.defaultButtonPressPoint"/>), a <see cref="InputActionType.Value"/>
+        /// action performs on any value change that isn't the default value, and a <see cref="InputActionType.PassThrough"/>
+        /// action performs on any value change including going back to the default value.
+        ///
+        /// Note that interactions (see <see cref="IInputInteraction"/>) can alter how an action does or does not progress through
+        /// the phases.
+        ///
+        /// For a given action, finding out whether it was performed in the current frame can be done with <see cref="InputAction.WasPerformedThisFrame"/>.
+        ///
+        /// <example>
+        /// <code>
+        /// action.WasPerformedThisFrame();
+        /// </code>
+        /// </example>
         /// </summary>
-        /// <seealso cref="InputAction.performed"/>
         Performed,
 
         /// <summary>
+        /// The action has stopped. Leads to <see cref="InputAction.canceled"/> getting called.
+        ///
+        /// By default, a <see cref="InputActionType.Button"/> action cancels when a control falls back below the button
+        /// press threshold (see <see cref="InputSettings.defaultButtonPressPoint"/>) and a <see cref="InputActionType.Value"/>
+        /// action cancels when a control moves back to its default value. A <see cref="InputActionType.PassThrough"/> action
+        /// does not generally cancel based on input on its controls.
+        ///
+        /// An action will also get canceled when it is disabled while in progress (see <see cref="InputAction.Disable"/>).
+        /// Also, when an <see cref="InputDevice"/> that is
         ///
+        /// Note that interactions (see <see cref="IInputInteraction"/>) can alter how an action does or does not progress through
+        /// the phases.
         /// </summary>
-        /// <seealso cref="InputAction.canceled"/>
         Canceled
     }
 }