Refactor UITK UI input tests and re-enable test on CI

[MorganHoarau]

Description

While testing #2349 locally, I noticed that UI_CanOperateUIToolkitInterface_UsingInputSystemUIInputModule was failing. Turns out the test have always been failing and was ignore on most platform (including linux - which run our CI).

UI_CanOperateUIToolkitInterface_UsingInputSystemUIInputModule was a long integration scenario that was doing:

• mouse press/capture/release
• scroll
• gamepad submit with uiButton.Focus()
• mouse device removal (pointer purge path)
• then multi-touch checks (both event and visual state based)

I was able to get the failing scenario (the UI element :active pseudo-state inconsistent behaviour) - by gradually disabling the integrated scenario. So my assumption is that the the pointer/event-data being reused across pointers and phases was causing touch pointers to inherit subtle stale event state after mouse/gamepad + purge transitions.

I then splitted the monolithic method into multiple focused UnityTests:

• mouse click
• mouse scroll
• gamepad submit
• multi-touch pointer ownership
• multi-touch visual active-state

...and added stronger assertions (including pointerId ownership checks), and clearer assertion messages.

Note that the original scenarios have been preserved, simply isolated to avoid the complexity of handling multiple devices properly in a test.

My hope is to re-enable those tests on CI and mobile platform.

Testing status & QA

Please describe the testing already done by you and what testing you request/recommend QA to execute. If you used or created any testing project please link them here too for QA.

Overall Product Risks

Please rate the potential complexity and halo effect from low to high for the reviewers. Note down potential risks to specific Editor branches if any.

• Complexity:
• Halo Effect:

Comments to reviewers

Please describe any additional information such as what to focus on, or historical info for the 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]

PR Reviewer Guide 🔍

Here are some key observations to aid the review process:

⏱️ Estimated effort to review: 3 🔵🔵🔵⚪⚪ Medium effort due to multiple new Unity integration tests with platform-conditional behavior, input-device lifecycle, and potential flakiness concerns.

🏅 Score: 86 Good refactor that improves test focus and assertions, but a few implementation details may cause CI flakiness or unintended platform coverage changes.

🧪 PR contains tests

🔒 No security concerns identified

⚡ Recommended focus areas for review Platform Coverage The platform-specific Ignore attributes appear to be commented out (using // #if ...), which may unintentionally re-enable tests on platforms where they were previously intentionally ignored; confirm this is desired and, if not, restore proper preprocessor directives. // #if UNITY_ANDROID || UNITY_IOS || UNITY_TVOS // [Ignore("Currently fails on the farm but succeeds locally on Note 10+; needs looking into.")] // #endif // #if UNITY_STANDALONE_LINUX || UNITY_EDITOR_LINUX // [Ignore("Disabled to make test suite pass on Linux")] // #endif Device Cleanup Some tests add input devices but do not explicitly remove them (notably the touchscreen in the multi-touch ownership test); ensure device teardown is consistent to avoid cross-test interference or reliance on fixture cleanup behavior. var touchscreen = InputSystem.AddDevice<Touchscreen>(); var scene = SceneManager.LoadScene("UITKTestScene", new LoadSceneParameters(LoadSceneMode.Additive)); yield return null; Assert.That(scene.isLoaded, Is.True, "UITKTestScene did not load as expected"); try { var objects = scene.GetRootGameObjects(); var uiModule = objects.First(x => x.name == "EventSystem").GetComponent<InputSystemUIInputModule>(); var uiDocument = objects.First(x => x.name == "UIDocument").GetComponent<UIDocument>(); var uiButton = uiDocument.rootVisualElement.Query<UnityEngine.UIElements.Button>("Button").First(); uiModule.pointerBehavior = pointerBehavior; yield return null; var buttonCenter = new Vector2(uiButton.worldBound.center.x, Screen.height - uiButton.worldBound.center.y); var buttonOutside = new Vector2(uiButton.worldBound.max.x + 10, Screen.height - uiButton.worldBound.center.y); var uiButtonDownCount = 0; var uiButtonUpCount = 0; var uiButtonDownPointerIds = new List<int>(); var uiButtonUpPointerIds = new List<int>(); uiButton.RegisterCallback<PointerDownEvent>(eventData => { uiButtonDownCount++; uiButtonDownPointerIds.Add(eventData.pointerId); }, TrickleDown.TrickleDown); uiButton.RegisterCallback<PointerUpEvent>(eventData => { uiButtonUpCount++; uiButtonUpPointerIds.Add(eventData.pointerId); }, TrickleDown.TrickleDown); BeginTouch(1, buttonCenter, screen: touchscreen); yield return null; Assert.That(uiButtonDownCount, Is.EqualTo(1), "Expected uiButtonDownCount to be 1"); Assert.That(uiButtonUpCount, Is.EqualTo(0), "Expected uiButtonUpCount to be 0"); Assert.That(uiButtonDownPointerIds, Has.Count.EqualTo(1), "Expected one PointerDown pointerId"); BeginTouch(2, buttonOutside, screen: touchscreen); yield return null; EndTouch(2, buttonOutside, screen: touchscreen); yield return null; Assert.That(uiButtonDownCount, Is.EqualTo(1), "Expected uiButtonDownCount to be 1"); if (pointerBehavior == UIPointerBehavior.SingleUnifiedPointer) { Assert.That(uiButtonUpCount, Is.EqualTo(1), "Expected uiButtonUpCount to be 1"); Assert.That(uiButtonUpPointerIds, Has.Count.EqualTo(1), "Expected one PointerUp pointerId"); } else { Assert.That(uiButtonUpCount, Is.EqualTo(0), "Expected uiButtonUpCount to be 0"); Assert.That(uiButtonUpPointerIds, Is.Empty, "Expected no PointerUp pointerId from outside touch"); } EndTouch(1, buttonCenter, screen: touchscreen); yield return null; Assert.That(uiButtonDownCount, Is.EqualTo(1), "Expected uiButtonDownCount to be 1"); Assert.That(uiButtonUpCount, Is.EqualTo(1), "Expected uiButtonUpCount to be 1"); Assert.That(uiButtonUpPointerIds, Has.Count.EqualTo(1), "Expected one PointerUp pointerId after releasing touch #1"); Assert.That(uiButtonUpPointerIds[0], Is.EqualTo(uiButtonDownPointerIds[0]), "Expected PointerUp ownership to match the pointer that pressed the button"); Assert.That(IsActiveVisualElement(uiButton), Is.False, "Expected uiButton to no longer be active"); } finally { SceneManager.UnloadSceneAsync(scene); } Test Reliability IsActiveVisualElement allocates by calling ToList() and relies on a query-based active pseudo-state check that may be timing-sensitive; consider using a non-allocating check and/or additional frame waits where needed to reduce intermittent failures. private static bool IsActiveVisualElement(VisualElement visualElement) { return visualElement.Query<VisualElement>().Active().ToList().Contains(visualElement); }

Update review

---

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

[u-pr]

PR Code Suggestions ✨

Explore these optional code suggestions:

Category	Suggestion	Impact
Possible issue	Check active state correctly Query() does not include the element itself, so this check can return false even when the element is actually active, making the new assertions unreliable. Use the element’s pseudoStates to directly test the Active state without allocations. Assets/Tests/InputSystem/Plugins/UITests.cs [4201-4204] private static bool IsActiveVisualElement(VisualElement visualElement) { - return visualElement.Query<VisualElement>().Active().ToList().Contains(visualElement); + return (visualElement.pseudoStates & UnityEngine.UIElements.PseudoStates.Active) != 0; } Suggestion importance[1-10]: 7 __ Why: The IsActiveVisualElement check using Query is likely incorrect because Query on a VisualElement searches its descendants; thus Contains(visualElement) would return false. Using pseudoStates directly is more accurate and avoids unnecessary allocations.	Medium
	Clean up created input devices Devices created via InputSystem.AddDevice<...>() should be removed even when assertions fail; otherwise later tests can see extra devices and behave differently. Remove the created device(s) in the finally block so cleanup always runs. Assets/Tests/InputSystem/Plugins/UITests.cs [4021-4050] public IEnumerator UI_UIToolkitInputModule_GamepadSubmit_ClicksFocusedButton() { var gamepad = InputSystem.AddDevice<Gamepad>(); var scene = SceneManager.LoadScene("UITKTestScene", new LoadSceneParameters(LoadSceneMode.Additive)); yield return null; Assert.That(scene.isLoaded, Is.True, "UITKTestScene did not load as expected"); try { ... } finally { + if (gamepad.added) + InputSystem.RemoveDevice(gamepad); SceneManager.UnloadSceneAsync(scene); } yield return null; } Suggestion importance[1-10]: 7 __ Why: Created input devices should be removed in a finally block to ensure test isolation, especially if an assertion fails. This ensures that the global InputSystem state is restored for subsequent tests.	Medium
	Wait for scene unload completion SceneManager.UnloadSceneAsync(scene) is asynchronous and a single yield return null may not guarantee the scene is fully unloaded, which can cause cross-test interference/flakiness on CI. Capture the unload operation and yield until it completes. Assets/Tests/InputSystem/Plugins/UITests.cs [3939-3968] +UnityEngine.AsyncOperation unloadOp = null; try { ... } finally { - SceneManager.UnloadSceneAsync(scene); + unloadOp = SceneManager.UnloadSceneAsync(scene); } -yield return null; +while (unloadOp != null && !unloadOp.isDone) + yield return null; Suggestion importance[1-10]: 6 __ Why: SceneManager.UnloadSceneAsync is an asynchronous operation. A single yield return null might not be sufficient to ensure the scene is fully unloaded, potentially leading to flakiness or cross-test interference.	Low
More 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                                          @@
##           fix/uum-100125/inactive-touch-drive-phantom-click-on-state-reset    #2367      +/-   ##
====================================================================================================
+ Coverage                                                             77.89%   77.92%   +0.02%     
====================================================================================================
  Files                                                                   476      476              
  Lines                                                                 97648    97748     +100     
====================================================================================================
+ Hits                                                                  76066    76173     +107     
+ Misses                                                                21582    21575       -7     

Flag	Coverage Δ
inputsystem_MacOS_2022.3	5.52% <ø> (ø)
inputsystem_MacOS_2022.3_project	75.43% <100.00%> (+0.02%)	⬆️
inputsystem_MacOS_6000.0	5.30% <ø> (ø)
inputsystem_MacOS_6000.0_project	77.33% <100.00%> (+0.03%)	⬆️
inputsystem_MacOS_6000.3	5.30% <ø> (ø)
inputsystem_MacOS_6000.3_project	77.32% <100.00%> (+0.03%)	⬆️
inputsystem_MacOS_6000.4	5.31% <ø> (ø)
inputsystem_MacOS_6000.4_project	77.33% <100.00%> (+0.02%)	⬆️
inputsystem_MacOS_6000.5	5.31% <ø> (ø)
inputsystem_MacOS_6000.5_project	77.32% <100.00%> (+0.02%)	⬆️
inputsystem_MacOS_6000.6_project	77.33% <100.00%> (+0.03%)	⬆️
inputsystem_Ubuntu_2022.3_project	75.33% <100.00%> (+0.12%)	⬆️
inputsystem_Ubuntu_6000.0	5.31% <ø> (ø)
inputsystem_Ubuntu_6000.0_project	77.23% <100.00%> (+0.13%)	⬆️
inputsystem_Ubuntu_6000.3	5.31% <ø> (ø)
inputsystem_Ubuntu_6000.3_project	77.22% <100.00%> (+0.12%)	⬆️
inputsystem_Ubuntu_6000.4	5.31% <ø> (ø)
inputsystem_Ubuntu_6000.4_project	77.23% <100.00%> (+0.12%)	⬆️
inputsystem_Ubuntu_6000.5	5.31% <ø> (ø)
inputsystem_Ubuntu_6000.5_project	77.23% <100.00%> (+0.12%)	⬆️
inputsystem_Ubuntu_6000.6	5.31% <ø> (ø)
inputsystem_Ubuntu_6000.6_project	77.23% <100.00%> (+0.13%)	⬆️
inputsystem_Windows_2022.3	5.52% <ø> (ø)
inputsystem_Windows_2022.3_project	75.55% <100.00%> (+0.02%)	⬆️
inputsystem_Windows_6000.0	5.30% <ø> (ø)
inputsystem_Windows_6000.0_project	77.46% <100.00%> (+0.03%)	⬆️
inputsystem_Windows_6000.3	5.30% <ø> (ø)
inputsystem_Windows_6000.3_project	77.45% <100.00%> (+0.02%)	⬆️
inputsystem_Windows_6000.4	5.31% <ø> (ø)
inputsystem_Windows_6000.4_project	77.45% <100.00%> (+0.01%)	⬆️
inputsystem_Windows_6000.5	5.31% <ø> (ø)
inputsystem_Windows_6000.5_project	77.45% <100.00%> (+0.01%)	⬆️
inputsystem_Windows_6000.6	5.31% <ø> (ø)
inputsystem_Windows_6000.6_project	77.45% <100.00%> (+0.02%)	⬆️

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

Files with missing lines	Coverage Δ
Assets/Tests/InputSystem/Plugins/UITests.cs	94.87% <100.00%> (+0.20%)	⬆️

... and 2 files with indirect coverage changes

🚀 New features to boost your workflow:

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