Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Would like "next" form behavior in Keyboard #11344

Closed
eseidelGoogle opened this issue Jul 21, 2017 · 53 comments
Closed

Would like "next" form behavior in Keyboard #11344

eseidelGoogle opened this issue Jul 21, 2017 · 53 comments

Comments

@eseidelGoogle
Copy link
Contributor

@eseidelGoogle eseidelGoogle commented Jul 21, 2017

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
Copy link
Contributor Author

@eseidelGoogle eseidelGoogle commented 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
Copy link
Contributor Author

@eseidelGoogle eseidelGoogle commented 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
Copy link
Member

@cbracken cbracken commented Aug 3, 2017

Related #10372 on iOS.

@cbracken
Copy link
Member

@cbracken cbracken commented 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:

  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
Copy link
Member

@Hixie Hixie commented Aug 4, 2017

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

@abarth
Copy link
Contributor

@abarth abarth commented Aug 4, 2017

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
Copy link
Contributor Author

@eseidelGoogle eseidelGoogle commented 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
Copy link
Contributor

@collinjackson collinjackson commented Aug 24, 2017

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

@xster
Copy link
Member

@xster xster commented Dec 13, 2017

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

@Hixie
Copy link
Member

@Hixie Hixie commented Dec 13, 2017

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

@Hixie Hixie modified the milestones: 3: Current Milestone, 4: Next milestone Dec 13, 2017
@Hixie
Copy link
Member

@Hixie Hixie commented Jan 3, 2018

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
Copy link

@nailgilaziev nailgilaziev commented Jan 19, 2018

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
Copy link

@sbilstein sbilstein commented Mar 6, 2018

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

@QoLTech
Copy link

@QoLTech QoLTech commented Mar 19, 2018

This is a feature that I would like as well.

Is there any workaround?

@Koseng
Copy link

@Koseng Koseng commented Mar 25, 2018

Really needed.

@franciscojunior
Copy link

@franciscojunior franciscojunior commented Apr 2, 2018

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

@FrantisekGazo
Copy link

@FrantisekGazo FrantisekGazo commented Apr 14, 2018

This is a really needed feature.

@FrantisekGazo
Copy link

@FrantisekGazo FrantisekGazo commented Apr 14, 2018

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
Copy link

@wengelef wengelef commented Apr 22, 2018

@FrantisekGazo
nice, also works with TextFormField#onFieldSubmitted

@stuartmorgan
Copy link
Contributor

@stuartmorgan stuartmorgan commented Feb 11, 2019

@GeertJohan Wiring up the tab key itself would be trivial, it's the automatic traversal chain that's the hard part; there's no way this could be solved that wouldn't address the desktop need.

@gspencergoog gspencergoog modified the milestones: April 2019, May 2019 Mar 19, 2019
gspencergoog added a commit that referenced this issue Apr 22, 2019
…30040)

Implements focus traversal for desktop platforms, including re-implementing the existing focus manager and focus tree.

This implements a Focus widget that can be put into a widget tree to allow input focus to be given to a particular part of a widget tree.

It incorporates with the existing FocusScope and FocusNode infrastructure, and has minimal breakage to the API, although FocusScope.reparentIfNeeded is removed, replaced by a call to FocusAttachment.reparent(), so this is a breaking change:

FocusScopeNodes must now be attached to the focus tree using FocusScopeNode.attach, which takes a context and an optional onKey callback, and returns a FocusAttachment that should be kept by the widget that hosts the FocusScopeNode. This is necessary because of the need to make sure that the focus tree reflects the widget hierarchy.

Callers that used to call FocusScope(context).reparentIfNeeded in their build method will call reparent  on a FocusAttachment instead, which they will obtain by calling FocusScopeNode.attach in their initState method. Widgets that own FocusNodes will need to call dispose on the focus node in their dispose method.

Addresses #11344, #1608, #13264, and #1678
Fixes #30084
Fixes #26704
gspencergoog added a commit that referenced this issue Apr 25, 2019
This re-lands the Focus changes in #30040. Correctness changes in routes.dart, and removes the automatic requesting of focus on reparent when there is no current focus, which caused undesirable selections.

Addresses #11344, #1608, #13264, and #1678
Fixes #30084
Fixes #26704
@gspencergoog gspencergoog added this to To do in Desktop Features May 2, 2019
gspencergoog added a commit that referenced this issue May 15, 2019
This implements focus and hover handling for Material buttons. It inserts Focus widgets into the tree in order to allow buttons to be focusable via keyboard traversal (a.k.a. TAB traversal), and Listener widgets into the InkWell to allow the detection of hover states for widgets.

Addresses #11344, #1608, and #13264.
@gspencergoog
Copy link
Contributor

@gspencergoog gspencergoog commented 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 gspencergoog modified the milestones: May 2019, July 2019 May 28, 2019
@stuartmorgan stuartmorgan added this to To do in Windows Preview Jun 11, 2019
@stuartmorgan stuartmorgan added this to To do in macOS Preview Jun 11, 2019
@stuartmorgan stuartmorgan added this to To do in Linux Preview Jun 11, 2019
@gspencergoog
Copy link
Contributor

@gspencergoog gspencergoog commented 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 nextFocus call.

macOS Preview automation moved this from To do to Done Jul 11, 2019
Windows Preview automation moved this from To do to Done Jul 11, 2019
Linux Preview automation moved this from To do to Done Jul 11, 2019
@filiph filiph added the a: annoyance label Sep 11, 2019
@escamoteur
Copy link
Contributor

@escamoteur escamoteur commented Sep 13, 2019

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

@gspencergoog gspencergoog moved this from To do to Done in Desktop Features Oct 9, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment