Deactivating UIDocument deactivates InputActions

Input
, , , ,
1

Heya everyone, recently I stumbled upon what I though to be a bug, where in Unity 6.2 disabling a UIDocument disabled my Player/Move action, as well as it turns out the whole InputActionAsset. See:

repro

It’s a fresh project with an empty UIDocument and a simple MonoBehaviour that reads an InputActionReference (in the example set to Player/Move) to move a cube. If you never add a UIDocument, this doesn’t happen. Whether you deactivate by code or via editor same result.

I reported it (IN-112535), but it turns out it is apparently by design. 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. (Info via the bug report)

That said I still wanted to share a solution/workaround in case someone else stumbles over this same problem, actually two of them even.

First the Unity recommended solution:

  • “If you need gameplay input to remain active when the UI is disabled, the recommended approach is to use separate InputActionAssets.” (Quote from the bug report)

Second, an alternative solution:

  • Always have an empty UIDocumentBehaviour(without Source Asset) active in your scene. That’s it.

My thoughts:

Neither solution is really ideal, the unity one because you now have to juggle two InputActionAssets, whereas with the alternative solution you’ll have to drag another gameobject into any scene where you get this problem. (Admittedly you might not ever really run into this problem since most of the time there is some UI around, and as long as there is at least one UIDocument nothing will go wrong.)

Personally I would like it most if UIDocuments wouldn’t suddenly disable the whole InputActionAsset, but shrug what can ya do. (Well… you can write a post on the discussion forums, like im doing rn :grinning_face_with_smiling_eyes: )

PS: Thank you to tobias_froihofer from “Input Icons for Input System” for discussion on this as well as suggesting the alt. solution.

2 Likes
2

Dang! I just updated my unity from 6.1 to 6.2 recently and I’m facing this issue. It doesn’t make sense to me that the application-wide input asset stops working on that scenario, since that is supposed to be a new input system to replace the old one (regardless of any UI).

Can you paste the link to IN-112535 ? I couldn’t find it.

3

Here you go: https://unity3d.atlassian.net/servicedesk/customer/portal/2/IN-112535
Although I’m not sure if its accessible by non-submitters/non-unity.

4

Yeah… I can’t access it. I wanted to see their original answer. Anyways, I went with the empty UIDocument workaround. Thank you for posting that!

5

Thanks for sharing this!
Regarding the second workaround (keeping an empty UIDocument active), I’ve found a way to make it much more manageable without having to manually drag a GameObject into every single scene.

The idea is to use a Persistent Scene that loads additively and stays active throughout the game. By placing the dummy UIDocument in a “Shared” scene and loading it at startup, you can ensure the InputActionAsset remains active project-wide.

Here is a simple script to automate this process:

using UnityEngine;
using UnityEngine.SceneManagement;

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

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

        // Check if "Shared" scene is already loaded
        for (int i = 0; i < SceneManager.sceneCount; i++)
        {
            if (SceneManager.GetSceneAt(i).name == "Shared") return;
        }

        // Load the scene containing the dummy UIDocument additively
        SceneManager.LoadSceneAsync("Shared", LoadSceneMode.Additive);
    }
}

How to setup:

Create a scene named “Shared” and place a GameObject with an empty UIDocument in it (no camera needed).

Add the “Shared” scene to your Build Settings.

Add this script to your project.

This ensures the dummy UI is always present regardless of which scene you start from, avoiding the “manual dragging” downside mentioned earlier. Hope this helps someone else facing the same Unity 6 behavior!

You may also be able to achieve something similar with a UIDocument that has a DontDestroyOnLoad setting.

FYI: I’ve written a bit more about this behavior and the setup on my blog here: https://tang3cko.hashnode.dev/why-inputactionasset-stops-working-after-scene-transitions-and-how-to-fix-it#heading-alternative-persistent-scene-additive-to-maintain-uidocument

6

Those answers are absolute dogshit, Unity staff needs to address this anti-pattern.

2 Likes