fix(input): default a single-line field's Return key to done - #177
Conversation
The default was `next`, and Flutter resolves `next` to `focusNode.nextFocus()`: the next FOCUSABLE widget, not the next text field. On a real form the traversal order runs through buttons, colour swatches and switches, so one Return key behaved two different ways on one screen. Measured on a status-page form: Return on Name moved focus to a segmented-control button and iOS dismissed the keyboard because nothing editable held focus, while Return on the field below happened to land on a textarea, so the keyboard stayed and the caret jumped. A key labelled Next that lands on a colour swatch is worse than one labelled Done. `done` is now the default, so Return does one predictable thing. Field-to-field advance is still available through `textInputAction`, and that is the only place the intent can be stated correctly: only the form knows its own field order, and whether the next focusable widget is the next input. Multiline keeps `newline`; a Return there inserts a line and the keyboard is dismissed from the toolbar instead.
|
Warning Review limit reached
Next review available in: 46 minutes Limit details: You’ve used the included review currently available. You've used all free OSS reviews for now. Wait for the free limit to reset to keep reviewing this public repository. How can I continue?Wait for the limit to reset, then comment An organization admin can change what happens after included review limits in Billing. How do review limits work?CodeRabbit enforces per-developer PR review limits within each organization. For paid Pro and Pro+ reviews, CodeRabbit uses a developer's included PR review attempts over the past 7 days to set the current hourly allowance. At typical activity levels, the full plan allowance applies. Higher sustained activity can lower the allowance until earlier attempts leave the 7-day window. Please refer docs for additional details. Review details⚙️ Run configurationConfiguration used: defaults Review profile: CHILL Plan: Pro Plus Run ID: 📒 Files selected for processing (5)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
Codecov Report✅ All modified and coverable lines are covered by tests. 📢 Thoughts on this report? Let us know! |
The old default was undocumented, so the change had nothing to contradict, which is its own problem: a reader had no way to know what the Return key would do before running the app. `doc/widgets/w-input.md` now states the resolved default in the props table and explains under Event Handling why `.next` is an opt-in rather than a default. The skill's forms reference gained section 10, since composing a form is exactly when an agent decides this and it had no guidance at all. It points at WKeyboardActions for the case where the advance order is not a clean run of adjacent fields. Skill version 2.12.0.
1 similar comment
1 similar comment
|
Note Kodizm (AI-generated). May contain mistakes; verify before acting. A three-line default flip that is correct, tested both ways, and synced across the four surfaces it touches - nothing blocking. Minor
Correctness spot-checks that came back clean
TestsBoth directions are pinned: the default now asserts Checks I ran
|
Resolves the CHANGELOG conflict: this branch opens a `### Changed` section where master had grown a `### Fixed` one, both inserted at the same position. Kept both, ordered Changed then Fixed per the subsection list in CLAUDE.md, with no wording changed on either side. `skills/wind-ui/SKILL.md` merged clean since both branches set the same 2.12.0.
Minor release, not a patch. The Return-key default on a single-line `WInput` moved from `TextInputAction.next` to `.done` (#177), which changes behaviour in every consumer that never passed `textInputAction`. Consumers are pinned with `^1.3.0`, so a patch would have landed that on everyone at the next `pub upgrade` with the version number saying nothing had changed. A minor still reaches them automatically, so the two layout fixes are not withheld, but the number now says to read the notes. Ships with those two fixes: a `justify-between` row no longer splits its width between a child that asked to grow and siblings that did not (#175), and `WKeyboardActions` hosts its toolbar in the root overlay so it lands on the keyboard rather than hundreds of points below the viewport (#176). Plus the CI fix that had every open PR red on a dirty checkout (#178) and the codeql-action bump (#174). Bump pubspec.yaml 1.3.0 -> 1.4.0 and promote ## [Unreleased] to ## [1.4.0] - 2026-08-21 in CHANGELOG.md, with the [1.4.0] link reference and the [Unreleased] compare link redirected to 1.4.0...HEAD. Sync example/pubspec.yaml, the dartdoc_options.yaml source-link tag, and the llms.txt version string. Move the wind-ui skill to the 1.4 line: the nine reference H1s plus the SKILL.md description and version marker.
1 participant
What
WInputdefaults a single-line field toTextInputAction.doneinstead ofTextInputAction.next. Multiline keepsnewline. An explicittextInputActionstill wins.Why
Flutter resolves
nexttofocusNode.nextFocus(), which is the next FOCUSABLE widget rather than the next text field. On a real form the traversal order runs through buttons, colour swatches and switches, so the same Return key did two different things on one screen.Measured on a status-page form whose order is
Name → [segmented control] → Slug → [8 colour swatches] → [Replace/Remove] → Initials → Description:Reported by a user as "why does Enter close the keyboard on one field and move to another on the next one". A key labelled Next that lands on a colour swatch is worse than one labelled Done.
Field-to-field advance stays available through
textInputAction, and that is the only place the intent can be stated correctly: only the form knows its own field order.Testing
doneand gains a companion asserting an explicitnextstill wins, so the default cannot be hardcoded past the parameter.Review pass (2026-08-21)
The original commit touched
lib/andtest/only, so the post-change syncCLAUDE.mdrequires was missing. Nothing indoc/or the skill stated the OLD default either, which is its own problem: a reader had no way to know what the Return key would do without running the app.doc/widgets/w-input.mdprops table said only "Keyboard action (e.g..done,.next)". It now states the resolved default, and the Event Handling section carries the reasoning:.nextisfocusNode.nextFocus(), so it is an opt-in for the case where the next focusable IS the next input.skills/wind-ui/references/forms.mdhad no guidance on this at all, which is the surface an agent reads while composing a form. New section 10 covers the default, the per-field.nextpattern, and points atWKeyboardActionsfor an explicit advance order.CHANGELOG.mdgained a### Changedentry flagged as a behavioural break, with the one-line path back for a form that relied on the old default.README.mdneeds nothing (no roster change). No example page change: nothing underexample/lib/passestextInputAction, so no demo promised the old behaviour.Note on the CHANGELOG section
This landed under
### Changed, not### Fixed. It is a bug fix in intent, but it changes the default behaviour of a public widget, and a consumer whose form happened to be ordered as a clean run of adjacent fields loses the Return-advances-field behaviour on upgrade. Filing it as a fix would hide that from anyone reading the release notes for breaking changes.Gates
Run locally on the branch tip:
dart format --set-exit-if-changed: 0 changed.dart analyze lib/ test/ example/lib/: No issues found../tool/coverage.sh 90: 1693 passed, 1 skipped, coverage 94.8%.python3 tool/check-docs.py: 0 issues across 72 doc pages.Lint & Teststays red here until #178 lands onmaster:flutter pub getrewritesanalysis_options.yamlmid-run anddart pub publish --dry-runthen fails on a dirty checkout. Nothing on this branch causes it.