FIX: MouseDownEvent is triggered when changing from Scene view to Game view (ISXB-1671) #2234
+220
−59
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
Proposed solution to fix ISXB-1671.
The bug reports a UITK event that shouldn't be triggered. This ocurrs due to a
InputSystemProvider
UI Click action being performed once the Editor is in play-mode and we select Game view tab when previously in Scene View.The action that is triggered provides the wrong mouse position. Essentially, an action is being performed for the mouse click/position that happened while out of focus in the Editor and triggered the focus regain. However, when
InputManager.OnUpdate()
is called, it assumes the game already is in focus, so there was no way to know if an event was triggered out of focus or not.The proposed solution is to filter and discard the events that happened immediately before focus was regained, by checking if they were received before the focus regain. In the diagram below, essentially we are discarding the "ofending" event - in red - that triggered an Input Action, which would then dispatch a UITK event through
InputSystemProvider
.Unrelated changes to bug-fix
I also did a small refactoring to put some conditions in their own functions so that can be easier to read through
InputManager.OnUpdate
. This is just a personal preference as it has been historically complicated to reason about all the conditions we have. This is still not perfect, but I hope it's a small improvement for others as well.If you want, you can have a look of the commit which contains the fix changes, 6157498. This doesn't have any refactoring yet and is easier to reason about.
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
,Added
sections.Area_CanDoX
,Area_CanDoX_EvenIfYIsTheCase
,Area_WhenIDoX_AndYHappens_ThisIsTheResult
.During merge:
NEW: ___
.FIX: ___
.DOCS: ___
.CHANGE: ___
.RELEASE: 1.1.0-preview.3
.After merge: