fix(opencode): sets input mode based on whether mouse vs keyboard is in use to prevent mouse events firing #9449
+43
−1
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.
What does this PR do?
Related to: #9435 which was present in the web apps.
In the opencode cli there is no distinguishing between when you are currently using the mouse or the keyboard. Due to this if you use keyboard events to navigate, mouse events will still fire. This leads to the highlighted/active item in menus jumping up to whatever the mouse is under since the "dom" (tui) moves around under the mouse triggering the events.
To fix this we can distinguish between if the user is actively using the keyboard and disable certain mouse events from firing while it is the active input mode. On mousemove we set the active mode back to the mouse and those events then continue to fire.
Before the fix note the highlighted item jumps up to wherever the mouse was:

After note the highlighted item does not jump to the item the mouse happens to be over while keyboard navigating:

Credit to @JosXa in https://github.com/anomalyco/opencode/pull/8797/changes for figuring out the behavior around mousemove events also being triggered when the filter occurs due to the background element moving around under the cursor causing TUI mousemove events to fire.
How did you verify your code works?
Using the app, see videos.
Fixes: #9448 #8799