Would like "next" form behavior in Keyboard

[eseidelGoogle]

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.

[eseidelGoogle]

#9363 is a related (but different) bug in our text input which is also obvious when attempting to build a sign-up screen.

[eseidelGoogle]

@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]

Related #10372 on iOS.

[cbracken]

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:

1. 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.
2. Implement support for a user-defined return key type. Currently we only support 'done'.
3. Implement the focus traversal behaviour when 'next' is pressed.
4. Enable the iOS nav back/forward input accessory view.
5. Enable the Android equivalent (I haven't looked into this, but assume one exists).
6. Additional: Improve the default widget traversal order -- ideally, I assume top-to-bottom, left-to-right (for LTR locales).
7. Additional: Support a user-defined traversal order.

[Hixie]

cc @abarth who may have ideas for how to do focus traversal

[abarth]

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.

[1] https://docs.flutter.io/flutter/widgets/FocusScopeNode/requestFocus.html

[eseidelGoogle]

Posse is interested in knowing if this is something reasonable to do in the next two weeks before their next release.

[collinjackson]

@cbracken is working on this. we are hoping to have something minimal next week, though not including custom focus order.

[xster]

Minor update: the challenge is that we have no semantics yet that defines ordering of form fields' traversal

[Hixie]

This doesn't fit our current priority list, so I'm moving it to a later milestone.

[Hixie]

For the record, we are not planning on working on this in the near future. Please let us know if that is a problem. Thanks.

[nailgilaziev]

Input data from keyboard to UI is a most important function in a mobile device on production.
So, topics related to working with native keyboards and ways of interaction with it, I consider very high priority.

[sbilstein]

I'm running into this issue with an app I am building. Is there a suggested workaround?

[QoLTech]

This is a feature that I would like as well.

Is there any workaround?

[Koseng]

Really needed.

[franciscojunior]

+1. I'm also running into this issue. Is there any workaround?

[FrantisekGazo]

This is a really needed feature.

[FrantisekGazo]

There is a workaround via FocusScope.

var focusNode = new FocusNode();
var TextField(focusNode: focusNode);

FocusScope.of(context).requestFocus(focusNode);

you can manually call this from the TextField#onSubmit.

But it would be great if this could be done automatically.

[wengelef]

@FrantisekGazo
nice, also works with TextFormField#onFieldSubmitted

[gspencergoog]

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]

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.

[escamoteur]

Peeps, that is so awesome but why does nobody knows about this? OK its pretty new :-)

[github-actions]

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.