FIX: Update navigation state on move action swap#2388
Draft
MorganHoarau wants to merge 1 commit intodevelopfrom
Draft
FIX: Update navigation state on move action swap#2388MorganHoarau wants to merge 1 commit intodevelopfrom
MorganHoarau wants to merge 1 commit intodevelopfrom
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Description
This is a PoC of a fix for this Slack thread: https://unity.slack.com/archives/C09Q7LYP9/p1773406813979019
Swapping
InputSystemUIInputModule.movewhile a control was in a non-zero state caused phantom Navigate events.SwapActionunhooks the old action's callbacks before disabling it, so the cancelled event triggered on disable never reachedOnMoveCallback. This leftm_NavigationState.moveis a staled state.This PR add a fix that reads the new action's current value immediately after the swap, resynching the cached state.
Note: I've thought of re-ordering the action disabling before the action call-backs are unhook (in
SwapAction), but that might introduce regression as it would means that any action in non default state (button pressed) would cause a released event on Swap. That might be closer to what is expected in some situation, but that another of those semantic situation. The point being that some users might already depend on existing behaviour and we don't want to introduce regression.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.
Comments to reviewers
Please describe any additional information such as what to focus on, or historical info for the reviewers.
Checklist
Before review:
Changed,Fixed,Addedsections.Area_CanDoX,Area_CanDoX_EvenIfYIsTheCase,Area_WhenIDoX_AndYHappens_ThisIsTheResult.During merge:
NEW: ___.FIX: ___.DOCS: ___.CHANGE: ___.RELEASE: 1.1.0-preview.3.