Repository navigation
fix(navigation): make screen back navigation pop only its own entry - #56
Merged
Merged
Conversation
Navigator.goBack() pops whatever is current, and every screen's back callback called it unconditionally. A second call - a double tap on the back arrow while the screen animates out, or a tap racing the save/delete navigation - could pop the screen beneath instead: back from edit could also leave details. At a non-start section root the repeat was worse: the first call switched to the start section, the second would pop whatever that section was drilled into. Add goBack(from: NavKey), which acts only while `from` is the current top entry, and pass each screen's own route from the posting and settings navigation entries. System back (NavDisplay.onBack, invoked once per popped entry) keeps the unkeyed goBack(). Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Code Coverage
|
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.
Why
Every screen's back callback called
Navigator.goBack(), which pops whatever screen is current. A second call from the same screen could therefore pop the screen beneath it. Two ways that can happen:For example, leaving the edit screen could also leave the details screen. At the root of a non-start section (Settings) it was worse. The first call switches to the start section, and the second pops whatever that section was drilled into, which the user never touched.
This was worked out from the code, not reproduced in the app.
What changed
Navigator.goBack(from: NavKey)acts only whilefromis the current top entry. Otherwise it does nothing. A second request from the same screen finds a different entry on top and is a no-op.route.NavDisplay.onBackkeeps the plaingoBack(), because Navigation 3 calls it once per popped entry.core:navigationgains one public function.Considered, not included
dropUnlessResumedon navigating clicks is the pattern in Android's UI events guidance. It works here:navigation3-ui1.1.2 that this project uses does the same in common code.It complements this change rather than replacing it:
LaunchedEffectis not a click.It touches every navigating click, so it's left for a separate change.
Verification
./gradlew checkpasses. Five newNavigatorTestcases:🤖 Generated with Claude Code