FIX: handled events still triggering actions when switching PlayerInput

[AswinRajGopal]

Description

Bug: https://issuetracker.unity3d.com/issues/setting-inputeventptr-dot-handled-to-true-does-not-prevent-actions-from-triggering-when-changing-devices
When InputUser.onUnpairedDeviceUsed marks eventPtr.handled = true, we expect no action to fire from that same
button press.
But on devices like DualSense, a single press can generate multiple input events. The handled flag only stops the
one event, and another event in the same press still triggers the action.

Root cause
The action system is driven by state change events. We can see different eventIds for the handled event vs the
action‑triggering event, so the action was coming from a separate input event.

Fix

• While dispatching InputSystem.onEvent, stop calling remaining listeners once handled becomes true.
• When an event is handled (policy = SuppressStateUpdates), temporarily suppress action processing for that device
  for the rest of the update (and next update).
• In InputActionState, skip processing control changes if the device is suppressed.

Testing status & QA

Manually verified using repro project + dualsense controller.

Overall Product Risks

• Complexity: Low
• Halo Effect: Low

Comments to reviewers

• Only applies when policy is SuppressStateUpdates and a listener explicitly sets handled = true.
• Normal input flow remains unchanged, however documentation update seems necessary.
• This simply makes “handled” cover the entire physical press, even if it arrives as multiple events.
• handled + no state update leaves the button “unpressed” in system state, and gamepad polling makes
  the next event look like a new press which is now prevented.

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 Area_CanDoX, Area_CanDoX_EvenIfYIsTheCase, Area_WhenIDoX_AndYHappens_ThisIsTheResult.
  • Performance tests.
  • Integration tests.
• 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.

[u-pr]

PR Reviewer Guide 🔍

(Review updated until commit 8c58fe7)

Here are some key observations to aid the review process:

⏱️ Estimated effort to review: 2 🔵🔵⚪⚪⚪ The changes are concise and focused, with clear regression tests. Understanding the event processing lifecycle is needed, but the diff itself is small.

🏅 Score: 92 The PR provides a robust fix for the double-activation issue on handled events by introducing a short-term action suppression mechanism. The solution is well-tested and handles the described edge cases correctly.

🧪 PR contains tests

🔒 No security concerns identified

⚡ Recommended focus areas for review Suppression Scope The SuppressActionsForDevice logic suppresses action processing for the entire device for the current and next update. While necessary to prevent the 'ghost' press on polling (as explained in the PR), this side effect means concurrent inputs on other controls of the same device will also be ignored during this brief window. This is likely acceptable given the 'unpairing/handling' context, but validating that this broad suppression doesn't negatively impact other SuppressStateUpdates use cases would be prudent. // Record the update step for a handled event so we can suppress actions for this device // in this update and the immediately following one (action processing may occur next step). private void SuppressActionsForDevice(InputDevice device) { if (m_InputEventHandledPolicy != InputEventHandledPolicy.SuppressStateUpdates || device == null) return; var deviceIndex = device.m_DeviceIndex; if (m_SuppressActionsForDeviceUpdate == null || deviceIndex >= m_SuppressActionsForDeviceUpdate.Length) Array.Resize(ref m_SuppressActionsForDeviceUpdate, deviceIndex + 1); m_SuppressActionsForDeviceUpdate[deviceIndex] = InputUpdate.s_UpdateStepCount; }

Update review

---

🤖 Helpful? Please react with 👍/👎 | Questions❓Please reach out in Slack #ask-u-pr

[u-pr]

PR Code Suggestions ✨

---

🤖 Helpful? Please react with 👍/👎 | Questions❓Please reach out in Slack #ask-u-pr

[codecov-github-com]

Codecov Report

All modified and coverable lines are covered by tests ✅

@@           Coverage Diff            @@
##           develop    #2340   +/-   ##
========================================
  Coverage    77.95%   77.96%           
========================================
  Files          476      476           
  Lines        97453    97420   -33     
========================================
- Hits         75971    75949   -22     
+ Misses       21482    21471   -11     

Files with missing lines	Coverage Δ
Assets/Tests/InputSystem/CoreTests_Events.cs	98.49% <ø> (-0.01%)	⬇️
...nputsystem/InputSystem/Actions/InputActionState.cs	92.81% <ø> (ø)
.../com.unity.inputsystem/InputSystem/InputManager.cs	91.73% <100.00%> (-0.04%)	⬇️
...putsystem/InputSystem/Utilities/DelegateHelpers.cs	62.77% <ø> (ø)

🚀 New features to boost your workflow:

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

[u-pr]

Test Plan

• Test plan approved by PR author
• Test execution in progress
• Test execution complete
• Ready for merge

---

Summary of Changes & Risk Assessment

Summary of Changes

This PR fixes a bug where physical button presses that generate multiple input events (common on controllers like DualSense) would still trigger actions even if the first event was marked as handled. The fix introduces a device-specific suppression window that prevents InputActionState from processing changes for a device for the current and subsequent update steps once an event is handled under the SuppressStateUpdates policy.

Risk Assessment

• High Risk Areas: None identified.
• Medium Risk Areas: Core event dispatching loop in InputManager, action triggering logic in InputActionState.
• Low Risk Areas: Utilities (DelegateHelpers), Changelog.

---

Test Scenarios

Functional Testing

• Verify Multi-Event Suppression: Using the new test case Events_HandledFirstEvent_DoesNotTriggerAction_OnSecondEventSameUpdate in CoreTests_Events.cs:L1260, ensure that when two events are queued and the first is marked handled, the action performed count remains 0.
• Policy Requirement Check: Verify that suppression only occurs when InputSystem.settings.inputEventHandledPolicy is set to SuppressStateUpdates.
• Listener Termination: Confirm that InputSystem.onEvent stops calling subsequent listeners immediately after one listener sets eventPtr.handled = true (via DelegateHelpers.cs:L110).

Regression Testing

• Standard Input Flow: Verify that normal button presses (where no listener marks the event as handled) still trigger actions as expected across different device types (Keyboard, Mouse, Gamepad).
• Device Reconnection: Ensure that the suppression array m_SuppressActionsForDeviceUpdate in InputManager handles device indices correctly if a device is removed and a new one is added (checking for potential out-of-bounds or stale suppression).
• Existing Suppression Tests: Run existing tests in CoreTests_Events.cs that were modified (e.g., Events_ShouldRespectHandledPolicyUponUpdateAndSuppressedPressTransitions) to ensure the updated expected values are correct.

🔍 Regression Deep Dive (additional risks identified)

• Performance (Memory Allocation): The array m_SuppressActionsForDeviceUpdate is resized in InputManager.cs:L3906. Verify no excessive allocations occur during normal gameplay with many devices.
• Cross-Update Suppression: Verify the logic in InputManager.cs:L3921 (lastUpdate + 1 == currentUpdate) correctly clears suppression after the 1-frame window.

Edge Cases

• Null Device Events: Verify SuppressActionsForDevice(device) handles null device scenarios gracefully without crashing (referenced in InputManager.cs:L3901).
• Simultaneous Multi-Device Handling: Test handling events from two different devices in the same frame; ensure suppression only applies to the device that sent the handled event.

---

_{💡 This test plan updates automatically when /test_plan is run on new commits. If you have any feedback, please reach out in #ai-qa}

---

🤖 Helpful? Please react with 👍/👎 | Questions❓Please reach out in Slack #ask-u-pr

[u-pr]

Persistent review updated to latest commit 94564dc

[jfreire-unity]

This looks like a behavior change. What is the reason to change this?

[AswinRajGopal]

We needed a explicit way to keep action suppression working across update steps. It will ensure that actions doesn't trigger on next update which shows up as a false positive press like reported in the bug. Please correct me if I'm wrong - my understanding is,

• With SupressStateUpdates, a handled press should not create started or performed in steps 1 or 2.
• This change is removing the 2nd step false positive press and keeps the policy intact.

[jfreire-unity]

Thanks, left some comments for clarification

[u-pr]

Persistent review updated to latest commit 8c58fe7