You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Would like "next" form behavior in Keyboard #11344
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.
@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.
I'd build the traversal using FocusNode rather 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.
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 nextFocus call.
This 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 -v and a minimal reproduction of the issue.
Activity
eseidelGoogle commentedon 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.
eseidelGoogle commentedon Jul 27, 2017
@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.
cbracken commentedon Aug 3, 2017
Related #10372 on iOS.
cbracken commentedon Aug 3, 2017
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:
Hixie commentedon Aug 4, 2017
cc @abarth who may have ideas for how to do focus traversal
abarth commentedon Aug 4, 2017
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
eseidelGoogle commentedon Aug 14, 2017
Posse is interested in knowing if this is something reasonable to do in the next two weeks before their next release.
collinjackson commentedon Aug 24, 2017
@cbracken is working on this. we are hoping to have something minimal next week, though not including custom focus order.
xster commentedon Dec 13, 2017
Minor update: the challenge is that we have no semantics yet that defines ordering of form fields' traversal
Hixie commentedon Dec 13, 2017
This doesn't fit our current priority list, so I'm moving it to a later milestone.
68 remaining items
Implement focus traversal for desktop platforms, shoehorn edition. (#…
[Re-Land] Implement focus traversal for desktop platforms. (#31614)
Implements focus handling and hover for Material buttons. (#31438)
gspencergoog commentedon May 28, 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.
gspencergoog commentedon Jul 10, 2019
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.escamoteur commentedon Sep 13, 2019
Peeps, that is so awesome but why does nobody knows about this? OK its pretty new :-)
github-actions commentedon Aug 28, 2021
This 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.