Dismiss keyboard when leaving the edit-player screen#657
Open
wyne wants to merge 2 commits into
Open
Conversation
The clear (x) button in the player editor focuses the input programmatically. If the screen is removed while that input is still the first responder, iOS keeps a dangling reference and re-shows the keyboard the next time a native view presents -- e.g. tapping the FAB to open the new-game player-count menu would pop up the keyboard too. Dismiss the keyboard on `beforeRemove` so the first responder resigns cleanly while the input is still mounted, matching the existing pattern in EditGame.tsx. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Contributor
The beforeRemove handler alone fired too late during the back transition to reliably resign the first responder. Add two more direct dismissals: - FloatingActionButton: dismiss the keyboard in MenuView.onOpenMenu, so a dangling first responder can't be restored alongside the player-count menu (the visible symptom). - EditPlayerScreen: dismiss synchronously in the Back button before goBack(), while the input is still mounted. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Contributor
|
Coverage after merging claude/xenodochial-thompson-e63792 into main will be
Coverage Report
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
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
1 participant
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
Repro: create a new game → edit a player → tap the clear (✕) button on the name field → tap Back → start the game and exit → tap the FAB to start another new game. The on-screen keyboard pops up alongside the player-count menu.
Root cause
The clear button calls
inputRef.current?.focus()to keep the field active after clearing the name — a programmatic focus that makes theTextInputthe keyboard's first responder. When the screen unmounts on Back, nothing resigns that first responder, so iOS keeps a dangling reference to the now-destroyed text field. Later, when the nativeMenuView(the player-count menu from the FAB) presents, UIKit re-evaluates first responders and restores the keyboard.That's why "hit the clear button" is the essential repro step — it's the only path that focuses the input programmatically without a real tap that iOS would otherwise clean up on back-navigation.
Fix
Dismiss the keyboard on
beforeRemoveinEditPlayerScreen, so the first responder resigns cleanly while the input is still mounted. This mirrors the existingbeforeRemovepattern already used inEditGame.tsx.Tests
beforeRemovelistener and asserts it callsKeyboard.dismiss().npx jest src/screens/EditPlayerScreen.test.tsx→ 31 passed.npx tsc --noEmit→ clean.🤖 Generated with Claude Code