Skip to content

Would like "next" form behavior in Keyboard #11344

Description

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

Activity

  1. eseidelGoogle commented on Jul 21, 2017

    @eseidelGoogle
    ContributorAuthor

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

  2. eseidelGoogle commented on Jul 27, 2017

    @eseidelGoogle
    ContributorAuthor

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

  3. cbracken commented on Aug 3, 2017

    @cbracken
    Member

    Related #10372 on iOS.

  4. cbracken commented on Aug 3, 2017

    @cbracken
    Member

    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.
  5. Hixie commented on Aug 4, 2017

    @Hixie
    Contributor

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

  6. abarth commented on Aug 4, 2017

    @abarth
    Contributor

    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

  7. eseidelGoogle commented on Aug 14, 2017

    @eseidelGoogle
    ContributorAuthor

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

  8. collinjackson commented on Aug 24, 2017

    @collinjackson
    Contributor

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

  9. xster commented on Dec 13, 2017

    @xster
    Member

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

  10. Hixie commented on Dec 13, 2017

    @Hixie
    Contributor

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

  11. modified the milestones: 3: Current Milestone, on Dec 13, 2017
  12. 68 remaining items

  13. gspencergoog commented on May 28, 2019

    @gspencergoog
    Contributor

    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.

  14. gspencergoog commented on Jul 10, 2019

    @gspencergoog
    Contributor

    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.

  15. added
    a: annoyanceRepeatedly frustrating issues with non-experimental functionality
    on Sep 11, 2019
  16. escamoteur commented on Sep 13, 2019

    @escamoteur
    Contributor

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

  17. github-actions commented on Aug 28, 2021

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

  18. locked as resolved and limited conversation to collaborators on Aug 28, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

Labels

a: annoyanceRepeatedly frustrating issues with non-experimental functionalitya: desktopRunning on desktopa: text inputEntering text in a text field or keyboard related problemsc: new featureNothing broken; request for a new capabilitycustomer: posse (eap)frameworkflutter/packages/flutter repository. See also f: labels.p: material_uimaterial_ui package in flutter/packages

Type

No type

Projects

No projects

    Milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions