FIX: UISelectable's OnSubmit and OnCancel are not triggered when using InputTestFixture with mock keyboard [ISXB-1561] #2228

K-Tone · 2025-08-28T08:30:09Z

Description

Here we attempt to address an ancient regression that happened when we moved from using the cached button states obtained via performed callbacks to using InputAction.wasReleasedThisFrame. The problem with wasReleasedThisFrame is that it gets updated before we can get control in tests, so there's really no direct way to trigger it from tests. That said, we have a simple caching approach here that hopefully works well.

Testing status & QA

Local testing, 4 new regression tests to cover for the cases where we trigger events from a mock keyboard, both with a frame delay as well as without a frame delay. QA pass pending.

Overall Product Risks

Complexity: Low
Halo Effect: Medium - as this is actually affecting both mock tests as well as regular user experience (InputSystemUIInputModule is needed for uGUI stuff to work with this package well, so potentially a lot of users)

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.

After merge:

Create forward/backward port if needed. If you are blocked from creating a forward port now please add a task to ISX-1444.

codecov-github-com · 2025-08-28T08:40:17Z

Codecov Report

All modified and coverable lines are covered by tests ✅

@@             Coverage Diff             @@
##           develop    #2228      +/-   ##
===========================================
- Coverage    68.14%   68.13%   -0.02%     
===========================================
  Files          367      367              
  Lines        53662    53679      +17     
===========================================
+ Hits         36570    36576       +6     
- Misses       17092    17103      +11

Flag	Coverage Δ
linux_2021.3_pkg	`5.45% <0.00%> (-0.01%)`	⬇️
linux_2021.3_project	`70.40% <100.00%> (+0.01%)`	⬆️
linux_2022.3_pkg	`5.23% <ø> (ø)`
linux_2022.3_project	`65.25% <100.00%> (+0.01%)`	⬆️
linux_6000.0_pkg	`5.23% <ø> (ø)`
linux_6000.0_project	`68.04% <100.00%> (+0.01%)`	⬆️
linux_6000.2_pkg	`5.23% <ø> (ø)`
linux_6000.2_project	`68.04% <100.00%> (-0.02%)`	⬇️
linux_trunk_pkg	`5.24% <ø> (ø)`
linux_trunk_project	`68.04% <100.00%> (+0.01%)`	⬆️
mac_2021.3_pkg	`5.45% <0.00%> (-0.01%)`	⬇️
mac_2021.3_project	`70.42% <100.00%> (+0.01%)`	⬆️
mac_2022.3_pkg	`5.22% <ø> (ø)`
mac_2022.3_project	`65.27% <100.00%> (+0.01%)`	⬆️
mac_6000.0_pkg	`5.23% <ø> (ø)`
mac_6000.0_project	`68.07% <100.00%> (+0.01%)`	⬆️
mac_6000.2_pkg	`5.23% <ø> (ø)`
mac_6000.2_project	`68.06% <100.00%> (+0.01%)`	⬆️
mac_trunk_pkg	`5.23% <ø> (ø)`
mac_trunk_project	`68.06% <100.00%> (+0.01%)`	⬆️
win_2021.3_pkg	`5.45% <0.00%> (-0.01%)`	⬇️
win_2021.3_project	`70.49% <100.00%> (+0.01%)`	⬆️
win_2022.3_pkg	`5.23% <ø> (ø)`
win_2022.3_project	`65.35% <100.00%> (+0.01%)`	⬆️
win_6000.0_pkg	`5.23% <ø> (ø)`
win_6000.0_project	`68.14% <100.00%> (+0.01%)`	⬆️
win_6000.2_pkg	`5.23% <ø> (ø)`
win_6000.2_project	`68.14% <100.00%> (+0.01%)`	⬆️
win_trunk_pkg	`5.23% <ø> (ø)`
win_trunk_project	`68.14% <100.00%> (+0.01%)`	⬆️

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

Files with missing lines	Coverage Δ
...InputSystem/Plugins/UI/InputSystemUIInputModule.cs	`93.22% <100.00%> (+0.09%)`	⬆️
...utsystem/InputSystem/Plugins/UI/NavigationModel.cs	`100.00% <100.00%> (ø)`

... 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.

Packages/com.unity.inputsystem/InputSystem/Plugins/UI/InputSystemUIInputModule.cs

K-Tone · 2025-08-28T10:10:42Z

Packages/com.unity.inputsystem/InputSystem/Plugins/UI/InputSystemUIInputModule.cs

@@ -2318,6 +2317,26 @@ private void OnTrackedDevicePositionCallback(InputAction.CallbackContext context
 #endif
        }

+        private void OnSubmit(InputAction.CallbackContext context)
+        {
+            m_SubmitCancelState.device = context.control.device;


This line is from OnSubmitCancelCallback that got removed

K-Tone · 2025-08-28T10:12:12Z

Packages/com.unity.inputsystem/InputSystem/Plugins/UI/InputSystemUIInputModule.cs

+        {
+            m_SubmitCancelState.device = context.control.device;
+
+            if (!context.ReadValueAsButton())


So the way this is expected to work is that if we got into the callback, then this button has been interacted with. If it's been interacted with, and it is not pressed, then it's been released. Does this sound correct? Any corner cases here?

Assets/Tests/InputSystem/Plugins/MockKeyboardWithUITests.cs

ekcoh

Thanks for looking into this, generally changes look good but I am still confused around why the code before the diff wasn't working as expected to I need to run this to give my final comments/feedback on the proposed fix. I'll get back to you.

Assets/Tests/InputSystem/Plugins/MockKeyboardWithUITests.cs

ekcoh · 2025-09-01T06:59:34Z

Assets/Tests/InputSystem/Plugins/MockKeyboardWithUITests.cs

+        base.TearDown();
+    }
+
+    private static bool[] FrameWaitingOptions = { true, false };


Great you added this to get coverage on both scenarios/flavours. Maybe even motivate this with an inline comment, e.g.
// Test scenarios for separating Press and Release into two separate frames or processing them in the same frame.
IMO it makes it easier to decipher the tests after that

Another option would be to make this an integer, framesToWait and let the above represent { 1, 0 }, then we could also easily extend it to case 2 as well where there is a "null frame" in between.

Right, fair. I have this comment right below, where it gets used: We'd like to test both options to be safe with rapid actions that happened within a single frame. Can totally do it here instead if you prefer. As to the integer wait frames - I don't know, can of course do that if you fancy but to me it looked there was no difference whether to wait for one frame or any other >0 amount of frames.

I gess it's fine as is, I cannot say if doing it in 2 non-consecutive frame impacts the logic or not.

ekcoh · 2025-09-01T07:05:39Z

@K-Tone looks like formatter needs to be run on the code

K-Tone · 2025-09-01T07:31:26Z

Thanks for looking into this, generally changes look good but I am still confused around why the code before the diff wasn't working as expected to I need to run this to give my final comments/feedback on the proposed fix. I'll get back to you.

Yes. The problem as I perceive it is that action.WasReleasedThisFrame actually relies on when an EventSystem.Update happened (which is just a regular MonoBehaviour, so it's really when we update all MonoBehaviours). Because of that it's really challenging to trigger a Release in code such that we do it before EventSystem.Update is called this frame. In the user example:

// There was some EventSystem.Update at some point in time...

Release(someButton); // Releasing a button via InputTestFIxture.Release

// Right now, if we say action.WasReleasedThisFrame, it will go true of course, but the InputSystemUIInputModule doesn't know about that, it will only get updated next time EventSystem is updated, which will be next frame actually...

yield return null; // waiting for a frame

// EventSystem.Update will happen before we continue from the yield above, but that's already next frame so action.WasReleasedThisFrame is false.

I believe it's not a problem for normal input that reads actual devices because it's assumably interacted with before scripts update. In these kinds of automations with mock keyboards we're just running off an unfortunate frequency/phase.

K-Tone · 2025-09-02T09:42:44Z

Packages/com.unity.inputsystem/CHANGELOG.md

@@ -9,7 +9,6 @@ Due to package verification, the latest version below is the unpublished version
 however, it has to be formatted properly to pass verification tests.

 ## [Unreleased] - yyyy-mm-dd
- Fixed InputControl picker not updating correctly when the Input Actions Window was dirty. [ISXB-1221](https://issuetracker.unity3d.com/product/unity/issues/guid/ISXB-1221)


I think my brain left the building when I filled that up, it should have totally been in another section. Moving now.

… was impossible to do automatic testing with mocks

ekcoh

I think this looks good. Great work @K-Tone

Pauliusd01 · 2025-09-04T05:54:27Z

Seems like the bug still reproes in the user project, waiting for changes

K-Tone requested a review from ekcoh August 28, 2025 08:34

K-Tone changed the title ~~Anthony/isxb 1561 inputsystemui mock keyboard~~ FIX: UISelectable's OnSubmit and OnCancel are not triggered when using InputTestFixture with mock keyboard Aug 28, 2025

K-Tone changed the title ~~FIX: UISelectable's OnSubmit and OnCancel are not triggered when using InputTestFixture with mock keyboard~~ FIX: UISelectable's OnSubmit and OnCancel are not triggered when using InputTestFixture with mock keyboard [ISXB-1561] Aug 28, 2025

K-Tone commented Aug 28, 2025

View reviewed changes

Packages/com.unity.inputsystem/InputSystem/Plugins/UI/InputSystemUIInputModule.cs Show resolved Hide resolved

K-Tone commented Aug 28, 2025

View reviewed changes

Assets/Tests/InputSystem/Plugins/MockKeyboardWithUITests.cs Show resolved Hide resolved

K-Tone commented Aug 28, 2025

View reviewed changes

Assets/Tests/InputSystem/Plugins/MockKeyboardWithUITests.cs Show resolved Hide resolved

K-Tone requested a review from Pauliusd01 August 29, 2025 07:17

ekcoh reviewed Sep 1, 2025

View reviewed changes

K-Tone commented Sep 2, 2025

View reviewed changes

K-Tone marked this pull request as ready for review September 3, 2025 07:18

K-Tone added 5 commits September 3, 2025 10:18

track the submit and cancel events using callbacks since otherwise it…

0b6defd

… was impossible to do automatic testing with mocks

add a set of tests to cover for the input system UI module regression

3d32896

fixup formatting

27b80ee

update the release notes

7f0bb03

Apply review feedback

9ffb53a

K-Tone force-pushed the anthony/isxb-1561-inputsystemui-mock-keyboard branch from b204ba9 to 9ffb53a Compare September 3, 2025 07:18

ekcoh approved these changes Sep 3, 2025

View reviewed changes

FIX: UISelectable's OnSubmit and OnCancel are not triggered when using InputTestFixture with mock keyboard [ISXB-1561] #2228

Are you sure you want to change the base?

FIX: UISelectable's OnSubmit and OnCancel are not triggered when using InputTestFixture with mock keyboard [ISXB-1561] #2228

Conversation

K-Tone commented Aug 28, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Description

Testing status & QA

Overall Product Risks

Checklist

Uh oh!

codecov-github-com bot commented Aug 28, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Codecov Report

Uh oh!

Uh oh!

K-Tone Aug 28, 2025

Choose a reason for hiding this comment

Uh oh!

K-Tone Aug 28, 2025

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

ekcoh left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

ekcoh Sep 1, 2025

Choose a reason for hiding this comment

Uh oh!

ekcoh Sep 1, 2025

Choose a reason for hiding this comment

Uh oh!

K-Tone Sep 2, 2025

Choose a reason for hiding this comment

Uh oh!

ekcoh Sep 3, 2025

Choose a reason for hiding this comment

Uh oh!

ekcoh commented Sep 1, 2025

Uh oh!

K-Tone commented Sep 1, 2025

Uh oh!

K-Tone Sep 2, 2025

Choose a reason for hiding this comment

Uh oh!

ekcoh left a comment

Choose a reason for hiding this comment

Uh oh!

Pauliusd01 commented Sep 4, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Uh oh!

K-Tone commented Aug 28, 2025 •

edited

Loading

codecov-github-com bot commented Aug 28, 2025 •

edited

Loading

Pauliusd01 commented Sep 4, 2025 •

edited

Loading