Repository navigation
[web] onSubmitted of TextField invoked if another TextField is clicked #49785
Description
In browsers onSubmitted of TextField invoked on Enter and if another TextField is clicked.
Expected:
- on
Enterclicked -onSubmittedinvocation; - on another
TextFieldclicked - only focus change (withoutonSubmittedinvocation).
Steps to Reproduce
class MyHomePage extends StatelessWidget {
@override
Widget build(BuildContext context) {
return Container(
color: Colors.white,
padding: const EdgeInsets.all(24.0),
child: Material(
child: Column(
mainAxisAlignment: MainAxisAlignment.spaceEvenly,
children: <Widget>[
TextField(
decoration: InputDecoration(hintText: 'TextField #1'),
onSubmitted: (text) {
print('TextField #1 onSubmitted: $text');
},
),
TextField(
decoration: InputDecoration(hintText: 'TextField #2'),
onSubmitted: (text) {
print('TextField #2 onSubmitted: $text');
},
),
],
),
),
);
}
}Doctor summary (to see all details, run flutter doctor -v):
[✓] Flutter (Channel beta, v1.13.6, on Linux, locale en_US.UTF-8)
[✓] Android toolchain - develop for Android devices (Android SDK version 29.0.0)
[✓] Chrome - develop for the web
[✓] Android Studio (version 3.5)
[✓] IntelliJ IDEA Community Edition (version 2019.2)
[✓] Connected device (3 available)
• No issues found!
Activity
yjbanov commentedon Jan 30, 2020
@a-marenkov The current behavior was implemented this way on purpose. Can you explain why you'd like a different behavior? Is it preventing you from implementing something?
/cc @nturgut
kunit1 commentedon Jan 31, 2020
I tested the supplied sample code and this is what I observed on master:
a. text-field is now focused (good)
a. text-field is now unfocused (good)
b. onSubmitted fires automatically (?)
I think the onSubmitted firing automatically makes sense to me.
a-marenkov commentedon Jan 31, 2020
@yjbanov @kunit1
onSubmittedfiring automatically makes sense to me as well and i would not have filed the issue, but:onSubmittedis not firing automatically if you tap anotherTextField.onSubmittedis not firing automatically if you tap anotherTextField.onEditingCompleteandonSubmittedare called. It saysCalled when the user submits editable content (e.g., user presses the "done" button on the keyboard)- but what are the other ways to "submit editable"?@yjbanov Here are couple of cases in which this behavior is bad:
I want on enter pressed
(obviously, there would be also some kind of a login button on a screen to perform the request, but that's another story)
So i put this logic either
onEditingCompleteoronSubmitted-> user enters email
-> preses enter and enters password
-> then decides to correct email (user mistyped email or wants to enter different email)
-> user clicks email TextField and here is the problem, it fires
onSubmittedand thus the requestI want on enter pressed move focus to next TextField, so i put this logic either
onEditingCompleteoronSubmitted.-> user enters text in first TextField
-> preses enter and enters text in second TextField
-> then decides to correct text in first TextField
-> user clicks on first TextField and here is the problem - for half a second the third TextField gets focused and then first TextField gets focused (it looks buggy for user)
Maybe, there's another way to implement cases above that i don't know.
On mobile i don't face this problems with this implementation.
P.S. I'm sorry, i think this issue should not really be about onSubmitted alone, but also about onEditingComplete (since it seems it's more appropriate to use for focus logic).
a-marenkov commentedon Jan 31, 2020
Update In the second case above to reproduce the bug it might take more than one click on another TextField. Try switching between TextFields back and forth (requires at least 3 TextFields).
a-marenkov commentedon Feb 3, 2020
@yjbanov Another case would be:
I have at least 2 TextFields in a ListView (somewhere at the end of it).
I want on enter pressed move focus to next TextField, so i put this logic either onEditingComplete or onSubmitted.
-> user scrolls downwards and enters text in first TextField
-> then decides to scoll upwards by dragging
-> drags the ListView, and here is the problem - ListView would scroll upwards by dragging and also would autoscroll downwards to second TextField (because it gets focused as user taps blanc space).
It looks buggy.
20 remaining items
nturgut commentedon Jun 4, 2020
@jlubeck I understand the confusion. You are right the documentation is not descriptive and leads to confusion. We should also have the behavior described per platform if there is a difference between them.
I'll discuss this with other member worked on text editing this week and update this issue (and the documentations).
kunit1 commentedon Jun 8, 2020
@nturgut It is fine that now the textfield will not submit its content when click on other parts of the page. But shouldn't the text-field lose focus just like any other standard web text-field? The change in this PR caused a regression in my opinion as now the text field will not lose focus when clicking away.
NicolasDionB commentedon Jun 15, 2020
Maybe it's a noob question but: where can I find in which version of Flutter will this update be found? I know it's been merged but I have a hard time finding when it's available in Flutter :) Thanks!
nturgut commentedon Jun 26, 2020
Sorry for the late reply. I checked with developers who frequently worked on text editing.
The current API:
(1) Both onEditingComplete and onSubmitted are called at the same time.
(2) onSubmitted (which has the value) is indicates user the text editing is complete.
(3) onEditingComplete is for overriding the default behavior of focus changes.
PR(flutter-team-archive/engine#18743) is added to put web in sync with the current API documentation.
As also suggested by @kunit1: If TextFields do not lose focus when other areas are clicked (mouse click or touch) by the user so web scenarios will be hard to implement. We need either the existing onEditingComplete callback to act differently than the onSubmit callback, and notify these blur event. Or we need to add a new callback to support development.
I am working on a document discussing these options. I'll add a link here.
NicolasDionB commentedon Jun 28, 2020
That's good to hear. Though the onSubmited beeing called when we click outside the editing field is kinda strange. We should at least receive a value saying what caused the "submission". In my opinion, changing focus out of the field is not a mark of submission but I understand someone might see it differently. For me, hitting the "enter" or "send" button would be submission, nothing else. In any case, if we can receive the cause of the said submission, that would be fine so just adding an argument to the handler would work for me.
ironpotter commentedon Jul 15, 2020
Found some workaround, that emulates onSubmit action and losing focus doesn't trigger onSubmit.
sayurikunugi commentedon Jul 16, 2020
@ironpotter
Thank you, your solution works for me!
Just 1 thing, if the user inputs enter in the middle of text, it's not working right, so, I changed
to
ironpotter commentedon Jul 19, 2020
@sayurikunugi Thank you. You're right.
pedromassangocode commentedon Sep 21, 2020
Hi @a-marenkov
I cannot reproduce this on latest
masterchannel.sample code
flutter doctor -v
Closing this as probably fixed. Could everyone who still has this problem please file a new issue with the exact description of what happens, logs, and the output of
flutter doctor -v.All system setups can be slightly different, so it's always better to open new issues and reference related issues.
github-actions commentedon Aug 12, 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.