[webui] Trigger TextInputAction.next/newline on tab/enter keypresses in single line text input elements.

[tauu]

On the web the expected behaviour of single line TextField / TextFormFields is that pressing tab will move the focus to the next input element. Switching focus between input elements is usually done in the onFieldSubmitted callback on mobile platforms (see also: editable_text.dart#L854) . Currently this is not possible on the web as TextEditingElement will never send a TextInputAction to flutter. This would in turn trigger the onFieldSubmitted callback (editable_text.dart#L1210) .

This PR changes TextEditingElement so that it will send a TextInputAction.next to flutter if the user presses the tab key and TextInputAction.newline if the enter key was pressed. It is also possible to distinguish between both action in the onFieldSubmitted callback as the TextField will automatically lose focus for TextInputAction.newline but not for TextInputAction.next (as documented in onEditingComplete ). Consequently the expected behaviour (tab -> next field, enter -> submit form) can be implemented in the onFieldSubmitted callback as in the following example:

TextFormField(
  focusNode: _focusNode,
  onFieldSubmitted: (String value) {
    if(_passFocusNode.hasPrimaryFocus) {
      // This field still has focus, therefore the callback was triggered by TextInputAction.next.
      _focusNode.nextFocus();
    } else {
      // This field has lost focus, therefore the callback was triggered by TextInputAction.newline.
      // Handle this case by e.g. submitting the form data.
    }
  }
)

[mdebbar]

The way this feature is supposed to work with Flutter is that the widget tells us what input action it's expecting (see TextInputConfiguration). Then, when user hits enter, we send whatever action the framework asked us to send.

Relevant lines of code:

• We receive Flutter's input configuration here.
• We decode Flutter's input configuration here.

[nturgut]

Thanks for sending out the PR! Can you please resolve the file conflicts?

[tauu]

@nturgut Conflict has been resolved and the PR is rebased to current master.

@mdebbar OK, should the patch be changed to send only the configured input action? That would not be a problem. Nevertheless, text fields on the web are able to generate two input actions (next/tab, newline/enter) whereas on mobile platforms they are only able to generate the configured input action. Therefore it might be advantageous to treat textfields a bit differently on these platforms to meet user expectations.

[mdebbar]

@tauu I agree about the difference between mobile and web. But today, all actions we send will go to the same callback EditableText.onSubmitted. So even if we send a next action, it'll be treated as a submission by the widget.

That being said, we are already working on a mechanism to support tabs and correctly switch focus to the next/previous text field, button, etc.