Skip to content

FIX: Avoid disabling project-wide actions on shutdown#2346

Open
AswinRajGopal wants to merge 9 commits into
developfrom
uum-134130/fix-project-wide-action-onshutdown
Open

FIX: Avoid disabling project-wide actions on shutdown#2346
AswinRajGopal wants to merge 9 commits into
developfrom
uum-134130/fix-project-wide-action-onshutdown

Conversation

@AswinRajGopal
Copy link
Copy Markdown
Collaborator

@AswinRajGopal AswinRajGopal commented Feb 17, 2026

Description

case: https://issuetracker.unity3d.com/product/unity/issues/guid/UUM-134130

Bug:
UI Toolkit now destroys its internal objects when there is no UI left in the scene, so InputSystemProvider.Shutdown() can run during play. During shutdown we unregister the UI actions, but the old code was
managing the whole action asset. With project-wide actions (InputSystem.actions), that meant we could affect input outside UI. With the default internal asset, not cleaning up at all could leave the UI map
enabled longer than intended.

Fix:
Scope the lifecycle to the UI action map only. On registration, InputSystemProvider now makes sure the UI map is enabled. On unregister/shutdown, it disables only that UI map, and only if this provider
enabled it. This avoids changing the enabled state of unrelated maps in InputSystem.actions while still cleaning up the default/internal UI actions correctly.

Testing status & QA

Added new test.
Verified manually using repro project.

Overall Product Risks

  • Complexity: Low
  • Halo Effect: Low

Comments to reviewers

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
Copy link
Copy Markdown
Contributor

u-pr Bot commented Feb 17, 2026

PR Reviewer Guide 🔍

(Review updated until commit 0771421)

Here are some key observations to aid the review process:

🎫 Ticket compliance analysis ✅

UUM-134130 - PR Code Verified

Compliant requirements:

  • Deleting a GameObject with a UIDocument component during Play mode must not remove project-wide Input Actions.
  • When the last UI is destroyed and the UI input provider shuts down, unrelated input state outside UI must remain unchanged.

Requires further human verification:

  • The fix should cover the play mode repro where the Input Debugger previously showed project-wide actions disappearing after deleting UIDocument.
⏱️ Estimated effort to review: 2 🔵🔵⚪⚪⚪

Small, focused changes with one new test make this PR quick to review, though the action-lifecycle logic needs careful scrutiny.

🏅 Score: 84

The fix is targeted and tested, but the new ownership logic still leaves one concrete action-state leak for disabled project-wide UI maps.

🧪 PR contains tests
🔒 No security concerns identified
⚡ Recommended focus areas for review

State leak

If the project-wide InputSystem.actions asset contains a UI map that starts disabled, this code enables that map during registration but never marks it for restoration on shutdown or action-asset changes. As a result, the provider can leave the user's project-wide UI map enabled after UI is destroyed, which changes project-wide input state outside the lifetime of the UI provider.

if (m_UIActionMap != null && !m_UIActionMap.enabled)
{
    // Don't take ownership of the UI map lifecycle for project-wide actions — the user manages those.
    m_ShouldDisableUIActionMapOnUnregister = m_InputActionAsset != InputSystem.actions;
    m_UIActionMap.Enable();
📜 Additional Context from files
Packages/.../InputForUI/InputSystemProvider.cs - Lines 656-694

Shows the implementation of SelectInputActionAsset, which reveals how m_InputActionAsset is set (either to InputSystem.actions or a default action asset). This is crucial for understanding why m_InputActionAsset != InputSystem.actions is used to determine m_ShouldDisableUIActionMapOnUnregister.

Packages/.../InputForUI/InputSystemProvider.cs - Lines 77-127

Shows the Initialize, Shutdown, and OnActionsChange methods of InputSystemProvider, which helps verify the lifecycle flow (specifically when SelectInputActionAsset, RegisterActions, and UnregisterActions are called).

  • Update review

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

@u-pr
Copy link
Copy Markdown
Contributor

u-pr Bot commented Feb 17, 2026

PR Code Suggestions ✨

Explore these optional code suggestions:

CategorySuggestion                                                                                                                                    Impact
General
Restore global state after test execution

The test modifies the global static state InputSystem.s_Manager.actions without
restoring it, which can cause side effects or failures in subsequent tests. Wrap the
test logic in a try-finally block to ensure that the original state is restored and
the temporary asset is properly destroyed, even if an assertion fails.

Assets/Tests/InputSystem/Plugins/InputForUITests.cs [111-119]

-InputSystem.s_Manager.actions = asset;
+var originalActions = InputSystem.s_Manager.actions;
+try
+{
+    InputSystem.s_Manager.actions = asset;
 
-m_InputSystemProvider.Initialize();
-Assert.That(asset.enabled, Is.True, "Project-wide actions should be enabled by provider initialization.");
+    m_InputSystemProvider.Initialize();
+    Assert.That(asset.enabled, Is.True, "Project-wide actions should be enabled by provider initialization.");
 
-m_InputSystemProvider.Shutdown();
-Assert.That(asset.enabled, Is.True, "Project-wide actions must remain enabled after provider shutdown.");
+    m_InputSystemProvider.Shutdown();
+    Assert.That(asset.enabled, Is.True, "Project-wide actions must remain enabled after provider shutdown.");
+}
+finally
+{
+    InputSystem.s_Manager.actions = originalActions;
+    Object.DestroyImmediate(asset);
+}
 
-Object.DestroyImmediate(asset);
-
Suggestion importance[1-10]: 8

__

Why: The test modifies the global static state InputSystem.s_Manager.actions. Without a try-finally block, an assertion failure would prevent the restoration of the original state and the destruction of the created asset, potentially causing test pollution and side effects in subsequent tests.

Medium
  • More suggestions

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

@codecov-github-com
Copy link
Copy Markdown

codecov-github-com Bot commented Feb 17, 2026

Codecov Report

All modified and coverable lines are covered by tests ✅

@@             Coverage Diff             @@
##           develop    #2346      +/-   ##
===========================================
+ Coverage    78.13%   78.83%   +0.70%     
===========================================
  Files          483      760     +277     
  Lines        98770   138560   +39790     
===========================================
+ Hits         77169   109227   +32058     
- Misses       21601    29333    +7732     
Flag Coverage Δ
inputsystem_MacOS_6000.0 5.33% <0.00%> (+0.01%) ⬆️
inputsystem_MacOS_6000.0_project 77.33% <100.00%> (+0.02%) ⬆️
inputsystem_MacOS_6000.3 5.33% <0.00%> (+0.01%) ⬆️
inputsystem_MacOS_6000.3_project 77.32% <100.00%> (+0.05%) ⬆️
inputsystem_MacOS_6000.4 5.33% <0.00%> (+0.01%) ⬆️
inputsystem_MacOS_6000.4_project 77.34% <100.00%> (+0.05%) ⬆️
inputsystem_MacOS_6000.5 5.32% <0.00%> (+0.01%) ⬆️
inputsystem_MacOS_6000.5_project 77.37% <100.00%> (+0.05%) ⬆️
inputsystem_MacOS_6000.6 5.32% <0.00%> (+0.01%) ⬆️
inputsystem_MacOS_6000.6_project 77.37% <100.00%> (+0.05%) ⬆️
inputsystem_Ubuntu_6000.0 5.33% <0.00%> (+0.01%) ⬆️
inputsystem_Ubuntu_6000.0_project 77.24% <100.00%> (+0.02%) ⬆️
inputsystem_Ubuntu_6000.3 5.33% <0.00%> (+0.01%) ⬆️
inputsystem_Ubuntu_6000.3_project 77.23% <100.00%> (+0.05%) ⬆️
inputsystem_Ubuntu_6000.4 5.34% <0.00%> (+0.01%) ⬆️
inputsystem_Ubuntu_6000.4_project 77.24% <100.00%> (+0.05%) ⬆️
inputsystem_Ubuntu_6000.5 5.32% <0.00%> (+0.01%) ⬆️
inputsystem_Ubuntu_6000.5_project 77.28% <100.00%> (+0.05%) ⬆️
inputsystem_Ubuntu_6000.6 5.32% <0.00%> (+0.01%) ⬆️
inputsystem_Ubuntu_6000.6_project 77.28% <100.00%> (+0.05%) ⬆️
inputsystem_Windows_6000.0 5.33% <0.00%> (+0.01%) ⬆️
inputsystem_Windows_6000.0_project 77.46% <100.00%> (+0.03%) ⬆️
inputsystem_Windows_6000.3 5.33% <0.00%> (+0.01%) ⬆️
inputsystem_Windows_6000.3_project 77.45% <100.00%> (+0.05%) ⬆️
inputsystem_Windows_6000.4 5.33% <0.00%> (+0.01%) ⬆️
inputsystem_Windows_6000.4_project 77.46% <100.00%> (+0.05%) ⬆️
inputsystem_Windows_6000.5 5.32% <0.00%> (+0.01%) ⬆️
inputsystem_Windows_6000.5_project 77.50% <100.00%> (+0.05%) ⬆️
inputsystem_Windows_6000.6 5.32% <0.00%> (+0.01%) ⬆️
inputsystem_Windows_6000.6_project 77.50% <100.00%> (+0.05%) ⬆️

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

Files with missing lines Coverage Δ
...ssets/Tests/InputSystem/Plugins/InputForUITests.cs 96.94% <100.00%> (+0.23%) ⬆️
.../Runtime/Plugins/InputForUI/InputSystemProvider.cs 86.72% <100.00%> (ø)

... and 215 files with indirect coverage changes

ℹ️ Need help interpreting these results?

@AswinRajGopal AswinRajGopal removed the request for review from Pauliusd01 February 17, 2026 11:43
UnregisterAction(ref m_ScrollWheelAction, OnScrollWheelPerformed);

if (m_InputActionAsset != null)
if (m_InputActionAsset != null && m_InputActionAsset != InputSystem.actions)
Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Do we actually have to disable the actions? I'm not a huge fan of disabling this for a particular asset, like project wide actions. I also think the logic we implemented in the past might not be the most correct.

I believe we should always make sure that the UI action map is enabled when registering the actions. Do you know what's the impact of not disabling this asset for a normal asset?

Copy link
Copy Markdown
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@jfreire-unity Thanks for the review, I agree that the current change only addresses the reported bug. I’ll improve the fix so that we explicitly ensure the UI action map is enabled when registering actions, and on unregister we only clean up state owned by the provider instead of disabling shared asset state.

@Pauliusd01
Copy link
Copy Markdown
Collaborator

/test_plan

@u-pr
Copy link
Copy Markdown
Contributor

u-pr Bot commented Mar 30, 2026

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 the InputSystemProvider would disable the entire InputActionAsset upon shutdown (e.g., when UI Toolkit objects are destroyed in-scene). This was problematic for project-wide actions (InputSystem.actions), as it would kill all input globally. The fix scopes the enable/disable lifecycle strictly to the "UI" action map and ensures the provider only disables the map if it was responsible for enabling it.

Risk Assessment

  • High Risk Areas: None identified.
  • Medium Risk Areas: Action map state management (ensuring maps aren't accidentally left enabled or disabled in complex UI transition scenarios).
  • Low Risk Areas: Unit test cleanup and static state management in tests.

Test Scenarios

Functional Testing

  • Project-wide Asset Preservation: Verify that when InputSystem.actions is assigned, calling Shutdown() on the provider does not call Disable() on the asset itself.
  • UI Map Specific Lifecycle: Verify that only the map named "UI" is toggled by the provider. If an asset has a "Gameplay" map and a "UI" map, "Gameplay" should remain untouched.
  • Conditional Disable Logic:
    • Case A: UI Map is already enabled by the user -> Provider Init -> Provider Shutdown -> UI Map stays enabled.
    • Case B: UI Map is disabled -> Provider Init (enables it) -> Provider Shutdown -> UI Map is disabled.

Regression Testing

  • Default Action Path: Verify that when no custom asset is used (default internal actions), the UI maps are still correctly enabled for standard UITK usage.
  • Test Suite Stability: Run InputForUITests.cs:L33 to ensure the new Shutdown_DoesNotDisableProjectWideActionsAsset test passes and doesn't pollute global state.
🔍 Regression Deep Dive (additional risks identified)
  • Manual UnregisterActions call: Verify that if InputSystemProvider.cs:L655 is called manually via internal APIs, the m_UIActionMap reference is correctly cleared to null to avoid leaking references to destroyed assets.
  • Missing "UI" Map: Verify behavior when the assigned InputActionAsset does not contain a map named "UI" (should fail gracefully/not throw null ref).

Edge Cases

  • Asset Swapping: If InputSystem.actions is changed after the provider has initialized, verify that Shutdown still behaves safely (the logic in RegisterActions captures the state of the asset active at that moment).

💡 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

@Pauliusd01
Copy link
Copy Markdown
Collaborator

Pauliusd01 commented Mar 30, 2026

I'm not entirely sure what the expected outcome should be. Is it expected that most actions including UI remain active when deleting the UI object? What about this one in the screenshot, what makes it special and why is it the only one that gets removed?
image

@AswinRajGopal
Copy link
Copy Markdown
Collaborator Author

I'm not entirely sure what the expected outcome should be. Is it expected that most actions including UI remain active when deleting the UI object? What about this one in the screenshot, what makes it special and why is it the only one that gets removed?

Hi @Pauliusd01 nextPreviousAction (no Asset) is the exception because it is not part of the project asset. The code creates it temporarily just for this UI provider and removes it again when the provider goes away. That is why it is the only one that disappears. @jfreire-unity Please correct me if I'm wrong.

@jfreire-unity
Copy link
Copy Markdown
Collaborator

Sorry I'll try to have a look at this in the next couple of days. Need to "load the context" of this area to make sure we're not introducing any other regression

@jfreire-unity
Copy link
Copy Markdown
Collaborator

/crc

Copy link
Copy Markdown
Contributor

@u-pr u-pr Bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

May require changes

The review has identified several significant issues that need to be addressed. The current implementation introduces a regression risk with a potential ArgumentException when custom assets are used. Additionally, there is a logic discrepancy in the fix itself that results in disabling portions of the project-wide action asset, which will likely cause the newly added test case to fail. Some minor improvements to test code consistency and maintenance are also recommended.

🤖 Helpful? 👍/👎

Comment thread Assets/Tests/InputSystem/Plugins/InputForUITests.cs Outdated
Comment thread Assets/Tests/InputSystem/Plugins/InputForUITests.cs Outdated
@AswinRajGopal
Copy link
Copy Markdown
Collaborator Author

Sorry I'll try to have a look at this in the next couple of days. Need to "load the context" of this area to make sure we're not introducing any other regression

Hi @jfreire-unity could you please review this PR? or can you suggest another reviewers from the team to move it forward? it is been a while on my name. Thanks in advance :)

Copy link
Copy Markdown
Collaborator

@jfreire-unity jfreire-unity left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

As mentioned in Slack, have a look at the U-PR suggestions to see if they make any sense. And feel free to look if we need to extend the added test to look into the action map that's being disabled.

@AswinRajGopal
Copy link
Copy Markdown
Collaborator Author

Currently working on U-PR comments,

@u-pr
Copy link
Copy Markdown
Contributor

u-pr Bot commented May 22, 2026

Persistent review updated to latest commit 0771421

@u-pr
Copy link
Copy Markdown
Contributor

u-pr Bot commented May 22, 2026

PR Code Suggestions ✨

No code suggestions found for the PR.

@AswinRajGopal AswinRajGopal requested a review from Pauliusd01 May 23, 2026 18:42
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants