fix: prevent Enter key infinite loop in interview notes mode#3450
Open
yokotoka wants to merge 2 commits intogsd-build:mainfrom
Open
fix: prevent Enter key infinite loop in interview notes mode#3450yokotoka wants to merge 2 commits intogsd-build:mainfrom
yokotoka wants to merge 2 commits intogsd-build:mainfrom
Conversation
Contributor
🟡 PR Risk Report — MEDIUM
Affected Systems
File Breakdown
|
Contributor
There was a problem hiding this comment.
Pull request overview
This PR fixes an interaction bug in the shared TUI interview flow where pressing Enter while editing notes could re-trigger the “auto-open notes on ‘None of the above’” behavior, trapping users in a loop and preventing progression.
Changes:
- Adds a
!states[currentIdx].notesVisibleguard to the “auto-open notes” condition ingoNextOrSubmit()to prevent re-opening notes after they’ve already been shown once for the current question. - Adds an inline comment clarifying why the guard exists (Enter-from-notes confirmation path).
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
added 2 commits
April 4, 2026 23:43
When pressing Enter to confirm notes in the interview UI, goNextOrSubmit() would re-open the notes field if the cursor was on "None of the above", creating an infinite loop where Enter never advanced past the question. The auto-open check (added in b80eec6 for gsd-build#2715) now also verifies that notes haven't already been shown (notesVisible === false), so it only triggers on the initial "None of the above" selection. Fixes gsd-build#3449
When pressing Enter to confirm notes in the interview UI, goNextOrSubmit() would re-open the notes field if the cursor was on 'None of the above', creating an infinite loop where Enter never advanced past the question. The auto-open check now also verifies that notes haven't already been shown (notesVisible === false), so it only triggers on the initial selection. Includes regression test for the guard condition. Fixes gsd-build#3449
4433809 to
f20de63
Compare
Collaborator
|
This PR has merge conflicts with the base branch. Please rebase or merge 🤖 Automated PR audit — 2026-04-04 |
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.
Summary
Fixes #3449
goNextOrSubmit()function in the interview UI re-opened the notes field every time Enter was pressed if the cursor was on "None of the above", creating an infinite loop where the user could never advance past the current question&& !states[currentIdx].notesVisibleguard to the auto-open condition so it only triggers on the initial selection, not when the user is confirming already-typed notesRoot Cause
Commit b80eec6 (#3081, fix for #2715) added auto-open logic that opens the notes field when "None of the above" is selected. However,
goNextOrSubmit()is also called when Enter is pressed from within notes mode (line 387). This created a cycle:focusNotes = false→goNextOrSubmit()goNextOrSubmit()seescursorIndex === noneOrDoneIdx→focusNotes = trueFix
The auto-open check now also verifies
!states[currentIdx].notesVisible. When notes have already been shown (notesVisible = truefrom the initial Tab or auto-open), the guard prevents re-opening and lets the flow advance normally.The original #2715 fix is preserved: when a user first selects "None of the above" (before notes have been shown),
notesVisibleisfalseand the auto-open still triggers correctly.Test plan
🤖 Generated with Claude Code