FIX: handled events still triggering actions when switching PlayerInput by AswinRajGopal · Pull Request #2340 · Unity-Technologies/InputSystem

AswinRajGopal · 2026-02-03T10:20:04Z

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 · 2026-02-03T10:21:58Z

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 · 2026-02-03T10:26:40Z

PR Code Suggestions ✨

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

codecov-fd.fxlcf.dpdns.org · 2026-02-03T10:27:26Z

Codecov Report

Attention: Patch coverage is 98.50746% with 1 line in your changes missing coverage. Please review.

Files with missing lines	Patch %	Lines
.../com.unity.inputsystem/InputSystem/InputManager.cs	96.96%	1 Missing ⚠️

@@             Coverage Diff             @@
##           develop    #2340      +/-   ##
===========================================
+ Coverage    77.95%   77.97%   +0.01%     
===========================================
  Files          476      476              
  Lines        97453    97526      +73     
===========================================
+ Hits         75971    76044      +73     
  Misses       21482    21482

Flag	Coverage Δ
inputsystem_Windows_6000.5_project	`77.51% <98.50%> (+0.01%)`	⬆️

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

Files with missing lines	Coverage Δ
Assets/Tests/InputSystem/CoreTests_Events.cs	`98.52% <100.00%> (+0.02%)`	⬆️
...nputsystem/InputSystem/Actions/InputActionState.cs	`92.81% <100.00%> (+<0.01%)`	⬆️
...putsystem/InputSystem/Utilities/DelegateHelpers.cs	`62.77% <ø> (ø)`
.../com.unity.inputsystem/InputSystem/InputManager.cs	`91.79% <96.96%> (+0.01%)`	⬆️

... and 1 file with indirect coverage changes

🚀 New features to boost your workflow:

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

u-pr · 2026-02-05T08:09:08Z

…objects

…n child objects" This reverts commit ee9aace.

u-pr · 2026-02-05T12:02:59Z

Persistent review updated to latest commit 94564dc

Packages/com.unity.inputsystem/InputSystem/InputManager.cs

jfreire-unity · 2026-02-05T12:11:38Z

Assets/Tests/InputSystem/CoreTests_Events.cs

+        new int[] { 0, 0, 0, 0, 1}, // started
+        new int[] { 0, 0, 0, 0, 1}, // performed
+        new int[] {0, 0, 0, 0, 0})] // cancelled
    // Press event is not detected in step 1/2 with default interaction
    [TestCase(InputEventHandledPolicy.SuppressActionEventNotifications,
        null,
        new int[] { 0, 0, 0, 0, 1},
        new int[] { 0, 0, 0, 0, 1},
        new int[] {0, 0, 0, 1, 1})]
-    // Press event is detected in step 2 (false positive) with explicit press interaction
+    // Press event is suppressed in step 1/2 with explicit press interaction
    [TestCase(InputEventHandledPolicy.SuppressStateUpdates,
        "press",
-        new int[] { 0, 0, 1, 1, 2},
-        new int[] { 0, 0, 1, 1, 2},
-        new int[] {0, 0, 0, 1, 1})]
+        new int[] { 0, 0, 0, 0, 1},
+        new int[] { 0, 0, 0, 0, 1},
+        new int[] {0, 0, 0, 0, 0})]


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

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.

I see. I'll keep looking at it to see if I find any problems. Meanwhile maybe @ekcoh has a more immediate answer since he added these tests.

Packages/com.unity.inputsystem/InputSystem/InputManager.cs

jfreire-unity

Thanks, left some comments for clarification

…ed(...) and no longer early-exit the event loop when eventPtr.handled is set

u-pr · 2026-02-09T09:58:28Z

Persistent review updated to latest commit 8c58fe7

Pauliusd01 · 2026-02-10T08:00:09Z

Did not forget this one, still looking into it

Pauliusd01

LGTM: Checked using the user project as well as our gamepad related sample scenes. Tried switching between mouse/keyboard/multiple gamepads in player and playmode, tried disconnecting/reconnecting as well as some of AI generated tests although those were a little bit "out there" and inconclusive. (Multiple listeners, Device switching, CrossUpdate supression, Rebinding supression) If there's anything specific you need me to recheck or you make changes after this then feel free to re-request the review

jfreire-unity · 2026-02-20T13:12:07Z

Packages/com.unity.inputsystem/InputSystem/InputManager.cs

                        }
                    }

+                    var currentEventPtr = new InputEventPtr(currentEventReadPtr);


I'm wondering if we need to cache this explicitly or if doing it the previous way is enough, by using currentEventReadPtr ? I don't see a reason but maybe I'm missing something.

ekcoh · 2026-02-20T14:20:57Z

Thanks for looking into this @AswinRajGopal and creating this PR.
I am just starting to look into this PR so will first just comment on what I am reacting to on the description level:

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.

A device like DualSense is often served by a polling (sampling) backend. It means it continuously reads its state and hence generate many events. It is true the handled flag only stops one event, but one should not stop any event from the perspective to update device state (this will break by design - which is why I added suppress mode originally since the original behaviour doesn't make any sense IMO). But if the transition from false, (suppressed), true yields a press interaction event we are already overboard. This is the exact same problem as @MorganHoarau is currently working with from the perspective of rotating a screen. Hence I believe this is a RCS/RCA issue again about false positives. I need to look into the diff here to say more but just wanted to mention this. I suspect the root cause for this issue lies in InputActionState if it allows interaction state to update when previous state was consumed/suppressed.

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.

This goes against the previous statement a bit. If there was a transition from false to true and true was suppressed, the following true should not be seen as a transition, since the transition is really true to true which is not a change.

These two comments aside, I agree with you if you concluded that you wanted to change suppression mode. This is problematic since it would lead to a behavioural change. I initially struggle to see why test case asserts would change though. I need some more time to give better feedback on this PR and analyse it properly.

ekcoh · 2026-02-20T14:22:47Z

Assets/Tests/InputSystem/CoreTests_Events.cs

-        new int[] { 0, 0, 1, 1, 2}, // started
-        new int[] { 0, 0, 1, 1, 2}, // performed
-        new int[] {0, 0, 0, 1, 1})] // cancelled
+        new int[] { 0, 0, 0, 0, 1}, // started


If any of this changes I suspect it will regress the rebinding sample.

AswinRajGopal added 3 commits February 3, 2026 15:48

Add test to cover the fix.

5a164b3

Fix handled unpaired device events still triggering actions

1fd3ec5

update Changelog

c950b4f

Fix failing test

75f5066

AswinRajGopal requested review from MorganHoarau, UnityAnthony and jfreire-unity February 4, 2026 07:58

Pauliusd01 requested review from K-Tone and Pauliusd01 and removed request for UnityAnthony February 5, 2026 07:43

ekcoh self-requested a review February 5, 2026 08:31

AswinRajGopal added 2 commits February 5, 2026 17:17

Fix : Allow isolated input raycast selection to accept hits on child …

ee9aace

…objects

Revert "Fix : Allow isolated input raycast selection to accept hits o…

94564dc

…n child objects" This reverts commit ee9aace.

jfreire-unity reviewed Feb 5, 2026

View reviewed changes

AswinRajGopal added 2 commits February 9, 2026 12:41

Listeners no longer use DelegateHelpers.InvokeCallbacksSafeUntilHandl…

2f1d804

…ed(...) and no longer early-exit the event loop when eventPtr.handled is set

Added inline comments to SupressActionsForDevice method.

8c58fe7

AswinRajGopal requested a review from jfreire-unity February 10, 2026 08:49

Pauliusd01 approved these changes Feb 10, 2026

View reviewed changes

jfreire-unity reviewed Feb 20, 2026

View reviewed changes

ekcoh reviewed Feb 20, 2026

View reviewed changes

Comments

Conversation

AswinRajGopal commented Feb 3, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Description

Testing status & QA

Overall Product Risks

Comments to reviewers

Checklist

Uh oh!

u-pr bot commented Feb 3, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

PR Reviewer Guide 🔍

(Review updated until commit 8c58fe7)

Uh oh!

u-pr bot commented Feb 3, 2026

PR Code Suggestions ✨

Uh oh!

codecov-fd.fxlcf.dpdns.org bot commented Feb 3, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Codecov Report

Uh oh!

u-pr bot commented Feb 5, 2026 • edited by Pauliusd01 Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Test Plan

Summary of Changes

Risk Assessment

Functional Testing

Regression Testing

Edge Cases

Uh oh!

u-pr bot commented Feb 5, 2026

Uh oh!

Uh oh!

jfreire-unity Feb 5, 2026

Choose a reason for hiding this comment

Uh oh!

AswinRajGopal Feb 9, 2026

Choose a reason for hiding this comment

Uh oh!

jfreire-unity Feb 20, 2026

Choose a reason for hiding this comment

Uh oh!

Uh oh!

jfreire-unity left a comment • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

u-pr bot commented Feb 9, 2026

Uh oh!

Pauliusd01 commented Feb 10, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Pauliusd01 left a comment

Choose a reason for hiding this comment

Uh oh!

jfreire-unity Feb 20, 2026

Choose a reason for hiding this comment

Uh oh!

ekcoh commented Feb 20, 2026

Uh oh!

ekcoh Feb 20, 2026

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

4 participants

AswinRajGopal commented Feb 3, 2026 •

edited

Loading

u-pr bot commented Feb 3, 2026 •

edited

Loading

(Review updated until commit `8c58fe7`)

codecov-fd.fxlcf.dpdns.org bot commented Feb 3, 2026 •

edited

Loading

u-pr bot commented Feb 5, 2026 •

edited by Pauliusd01

Loading

jfreire-unity left a comment •

edited

Loading

Pauliusd01 commented Feb 10, 2026 •

edited

Loading