Repository navigation
Would like "next" form behavior in Keyboard #11344
Description
Activity
- addeda: text inputEntering text in a text field or keyboard related problemsEntering text in a text field or keyboard related problems
on Jul 21, 2017 #9363 is a related (but different) bug in our text input which is also obvious when attempting to build a sign-up screen.
@cbracken Posse would like to try and work this support into the next release of their app. When you get back, would be interested in learning how hard this will be to do.
Related #10372 on iOS.
In terms of the work here, the main issue is that we don't currently define a navigation order over widgets.
My guestimate at the work involved:
- Determine the minimal default widget traversal order. We could use what we use for accessibility today, which is a traversal of the render tree, IIRC.
- Implement support for a user-defined return key type. Currently we only support 'done'.
- Implement the focus traversal behaviour when 'next' is pressed.
- Enable the iOS nav back/forward input accessory view.
- Enable the Android equivalent (I haven't looked into this, but assume one exists).
- Additional: Improve the default widget traversal order -- ideally, I assume top-to-bottom, left-to-right (for LTR locales).
- Additional: Support a user-defined traversal order.
cc @abarth who may have ideas for how to do focus traversal
I'd build the traversal using
FocusNoderather than the render tree. Currently, you only need to register your FocusNode with the FocusScopeNode when you requestFocus [1], you we should add another way of registering the FocusNode for traversal.If you want to get fancy, you could register with a BuildContext and then traversal could use your global coordinates to guess a default traversal order.
[1] https://docs.flutter.io/flutter/widgets/FocusScopeNode/requestFocus.html
Posse is interested in knowing if this is something reasonable to do in the next two weeks before their next release.
@cbracken is working on this. we are hoping to have something minimal next week, though not including custom focus order.
Minor update: the challenge is that we have no semantics yet that defines ordering of form fields' traversal
This doesn't fit our current priority list, so I'm moving it to a later milestone.
68 remaining items
- added a commit that references this issue
on May 15, 2019 This issue is blocked by needing the shortcut key map implementation (issue #13264), and by adding a connection for a soft keyboard "next" button (when used in place of the Done button) to be wired to call nextFocus on the currently focused widget.
OK, the shortcut key map implementation is in, so this is just blocked now by not having the connection between the soft keyboard "next" button being pressed and the
nextFocuscall.Reacted by Vincent Långström and Marcin Szałek- addeda: annoyanceRepeatedly frustrating issues with non-experimental functionalityRepeatedly frustrating issues with non-experimental functionality
on Sep 11, 2019 Peeps, that is so awesome but why does nobody knows about this? OK its pretty new :-)
Reacted by Marcin SzałekThis thread has been automatically locked since there has not been any recent activity after it was closed. If you are still experiencing a similar issue, please open a new bug, including the output of
flutter doctor -vand a minimal reproduction of the issue.- locked as resolved and limited conversation to collaborators
on Aug 28, 2021
Normally when filling out a form on iOS or Android the "done" key turns into a "next" key and you don't have to dismiss the keyboard between text fields.
If you try our "Text fields" demo in the flutter_gallery it does not have this expected "next" behavior.
I ran into this initially in Posse's app in the sign-up screen.