Engineering

Why InputActionAsset Stops Working After Scene Transitions (And How to Fix It)

PUBLISHED
  • Unity
  • Input System
  • UI Toolkit
  • UIDocument
  • C#
  • Game Development

🙇‍♂️ Correction: This article originally stated that the issue could be resolved with Instantiate, which was incorrect. The actual cause is Unity’s behavior where “disabling all UIDocuments also disables the InputActionAsset.” Input stops working when UIDocument is disabled or destroyed during scene transitions.

During Unity 1 Week Game Jam (ja: “Unity1週間ゲームジャム”, a popular game jam event on unityroom), I developed a game called Scoop & Cheers Battler. While building the title screen with UI Toolkit, I encountered a frustrating issue:

Input stops responding after scene transitions.

unityroomScoop & Cheers BattlerA Unity 1 Week Game Jam entry by tang3cko, hosted on unityroom — Japan's go-to platform for Unity-made browser games.

After investigation, I found the root cause: When all UIDocuments are disabled, the entire InputActionAsset assigned to UI gets disabled. This is Unity’s intended behavior, not a bug.

I ended up fixing it by adding UI Toolkit to all screens.

Environment

  • Unity … 6000.3.1f1
  • Input System … 1.17.0

Reproducing the Problem

Consider this setup:

  • Title screen: Built with UI Toolkit (has UIDocument)
  • Game screen: Using uGUI or custom implementation (no UIDocument)

The problem occurs with these steps:

  1. Title screen (with UIDocument) works fine
  2. Transition to game screen (UIDocument gets destroyed)
  3. Input no longer responds

In my game, I built the title screen with UI Toolkit, but subsequent screens had no UIDocument. The issue hit me perfectly — going through the title screen made the game unplayable.

GitHubtang3cko/Debug_UnresponsiveUIActionReproduction repository for the Unity InputActionAsset / UIDocument scene-transition issue.

The Cause

According to this Unity Discussions thread, this is intended behavior in Unity 6.2+ (not a bug).

Specifically any InputActionAsset assigned to UI (even the project-wide one, and yes the Asset not an ActionMap) will be disabled when all UIDocuments have been disabled.

When all UIDocuments are disabled, the InputActionAsset assigned to UI (including project-wide actions) gets disabled entirely.

Here’s how it works:

sequenceDiagram
    participant Title as Title Screen<br/>with UIDocument
    participant Asset as InputActionAsset
    participant Game as Game Screen<br/>without UIDocument

    Title->>Asset: UIDocument is active
    Note over Asset: InputActionAsset enabled

    Title->>Game: Scene transition
    Game->>Asset: All UIDocuments disabled
    Note over Asset: InputActionAsset gets disabled
    Note right of Game: Input stops working

Solutions

Use Separate InputActionAssets

According to the thread:

“If you need gameplay input to remain active when the UI is disabled, the recommended approach is to use separate InputActionAssets.”

Use different InputActionAssets for UI and gameplay.

This requires managing two separate InputActionAssets, but it seems like the better approach.

Alternative: Always Keep a UIDocument Active

A simpler solution is to place a UIDocument in every scene.

Even an empty UIDocument (without Source Asset) works fine. As long as at least one UIDocument remains active, the InputActionAsset stays enabled.

// Just place a GameObject with an empty UIDocument
// Source Asset doesn't need to be set
[RequireComponent(typeof(UIDocument))]
public class EmptyUIDocumentHolder : MonoBehaviour
{
    // Do nothing
}

Alternative: Persistent Scene (Additive) to Maintain UIDocument

Instead of placing an empty UIDocument in every scene, you can keep a scene loaded that contains a UIDocument.

No matter which scene you start from, the persistent scene is automatically loaded.

public static class CommonSceneLoader
{
    [RuntimeInitializeOnLoadMethod(RuntimeInitializeLoadType.BeforeSceneLoad)]
    private static void LoadCommonScene()
    {
        SceneManager.sceneLoaded += OnSceneLoaded;
    }

    private static void OnSceneLoaded(Scene scene, LoadSceneMode mode)
    {
        if (scene.name == "Common") return;

        // Load Common scene additively if not already loaded
        for (int i = 0; i < SceneManager.sceneCount; i++)
            if (SceneManager.GetSceneAt(i).name == "Common") return;

        SceneManager.LoadSceneAsync("Common", LoadSceneMode.Additive);
    }
}

Place only a GameObject with an empty UIDocument in Common.unity (no camera needed). You need to add the scene to Build Settings, but the benefit is you won’t miss adding it to any scene.

What Did I Do During the Game Jam?

For the battler game, I ended up adding UI Toolkit to all screens, which unintentionally made it work.

  • Title screen — TitleScreen.uxml
  • Preparation screen — PreparationScreen.uxml
  • Battle screen — GameScreen.uxml

Since every scene now has a UIDocument, the InputActionAsset never gets disabled. During the game jam, I casually thought “let’s just add UI Toolkit to all screens,” and it worked out well.

Comparison of Solutions

SolutionProsCons
Separate InputActionAssetsProper separation of Input Action managementNeed to manage two assets
Empty UIDocument in each sceneMinimal changesRequires adding to each scene, easy to miss
Persistent Scene (Additive)No missed placements, centralized managementNeed to add scene to Build Settings
Full UI ToolkitConsistent UI implementationMigration cost for existing UI, less flexible than uGUI

Summary

  1. In Unity 6.2+, disabling all UIDocuments also disables the InputActionAsset
  2. This is “by design”, not a bug
  3. The fix is to “always keep at least one UIDocument active”
  4. Adding UI Toolkit to all screens is the quickest solution

I hit this issue while building a UI Toolkit title screen during the game jam. Initially, I thought it was caused by InputActionAsset state sharing, but the real cause was the UI Toolkit and Input System integration behavior.

I hope this helps anyone facing the same problem.

Special Thanks

I received feedback on the initial version of this article, which helped me discover and investigate the behavior differences depending on UIDocument presence and the reproduction conditions.

  • @Hyoga — Not only provided feedback, but also helped with reproduction testing

References