Conversation
After navigating history with ArrowUp, the cursor was placed at the end of the input. But the ArrowUp handler only fires when the cursor is at position 0 (start). So the second ArrowUp just moved the cursor from end to start (default textarea behavior), wasting a keystroke. Fix: place cursor at start when navigating up, and at end when navigating down, so the next same-direction press fires immediately. Extract CommandHistory model class for testability. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
When navigating up through history the Blazor handler sets cursor to position 0. The JS atEnd guard then blocked ArrowDown (cursor not at end), requiring 2 keystrokes per down-step — symmetric to the original bug. Fix: - Add CommandHistory.IsNavigating (true while _index < entries.Count) - JsNavigateHistory now returns bool indicating whether navigation is still active - JS keydown handler tracks per-session nav state in window.__histNavActive via .then() on the async invoke; ArrowDown fires when atEnd OR histNavActive Also adds IsNavigating unit test. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
PureWeen
force-pushed
the
fix/when-using-up-arrow-to-list-preview-comm-20260224-2002
branch
from
6f6eed2 to
7f0cf84
Compare
- Add delegated 'input' event listener inside __dashboardKeydownRegistered guard that sets window.__histNavActive[session] = false when user types, preventing ArrowDown from overwriting in-progress edits after ArrowUp - Add .catch() to JsNavigateHistory Promise so a failed interop round-trip resets the flag instead of leaving it stuck true Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
PureWeen
deleted the
fix/when-using-up-arrow-to-list-preview-comm-20260224-2002
branch
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
2 participants
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.
Problem
When using up-arrow to navigate command history, it takes 2 keystrokes per command instead of 1.
Root Cause
After
JsNavigateHistorysets the input text, the cursor was always placed at the end of the input (el.value.length). However, the ArrowUp handler only fires when the cursor is at position 0 (atStart). So the sequence was:atStartis false → handler doesn't fire → default textarea behavior moves cursor to start (wasted keystroke)Fix
Place cursor at position 0 when navigating up (so next ArrowUp fires immediately), and at end when navigating down (so next ArrowDown fires immediately).
Also extracted
CommandHistorymodel class from inline Dashboard.razor logic for testability.Tests
Added
CommandHistoryTests.cswith 10 tests covering:CursorAtStart = trueCursorAtStart = false