fix: Autofocus confirm password textfield on password field submission.

[CyberWake]

What

• This PR fixes the auto focus of confirm password text field on submission of password field.

Screenshot

Before	After

Fixes bug(s)

• Bug: Confirm password field doesn't come to focus on submission of Password field unlike other fields(Signup Page) #1286

[g123k]

Thanks for your PR @CyberWake.
However I think a generic solution would be better here.

Instead of doing the focus trick on the password field only, it would be better to:

• Add a nextFocus optional field to SmoothTextFormField
• If it's provided, do your call in the onFieldSubmitted

[M123-dev]

I'm sure your way also works, but have you tried setting the textInputAction for the last field to TextInputAction.done, besides of that I can't think of why the focus move doesn't work for the last one

[CyberWake]

So setting the textInputAction to TextInputAction.done for the confirm password field won't work I guess since the issue starts with the internal mechanism of flutter I guess since the control doesn't get passed automatically ideally the focus passes to the next field inside the for without use of focusNode or textInputAction. But sometimes this doesn't happen due to some reasons like use of obscure field etc. Then in that case we explicitly need to use this focusNode mechanism.

[CyberWake]

Thanks for your PR @CyberWake. However I think a generic solution would be better here.

Instead of doing the focus trick on the password field only, it would be better to:

• Add a nextFocus optional field to SmoothTextFormField
• If it's provided, do your call in the onFieldSubmitted

Surely I try this one since this reduces passing of one argument. Good suggestion hope this works. 🤞🏻

[CyberWake]

I have an input from my side to stand the current implementation. Like in my case I have added the condition if the confirm password is not same as password then only focus to confirm password field this custom logic cannot be added if we implement that common way of using nextFocus. What I mean to say is like in my methodology if the user fills in the email field suppose first then he fills in the name field now via my mechanism we can directly add this logic to move the focus to directly to username field reducing user clicks. With nextFocus mechanism he would have to first submit name field then email field which was already filled and then again he needs to submit the email field to reach username field.

Secondly in nextFocus methodology we'll still need to pass the focus for the current field like for confirm password SmoothTextFormField we'll need to pass the focus to uniquely identify the confirm password fields focus. So the reduction of argument won't we a case which I just got.

Let me know you input on this.

[CyberWake]

@M123-dev could you please update me on this PR.

[g123k]

I guess you can my solution can easily be implemented.
Actually, you have two arguments:

• A nextFocus, to allow the call of FocusScope.of(...)
• A callback of type bool Function(String?), where you express if the call to nextFocus should be done or not

[CyberWake]

@g123k the solution suggested still need the two argument one the focusNode of the current field and the nextFocus which you want the focus to move after submit. As the nextFocus stand alone cannot move the focus to next textField since the value of nextFocus needs to be assigned as a focusNode to some textfield.

[M123-dev]

Then lets leave it like that, just two small things to sum up

1. I could imagine it beeing a bit confusing if sometimes you jump to the second password and another time two steps further. Its certainly great when you know it, but when not not
2. Please add a comment here and where you create the Focus node that there was a bug and thats why we have this hacky way for changing the focus only for one field

[CyberWake]

@M123-dev sure I'll do the points marked out.

[M123-dev]

Any update @CyberWake

[teolemon]

merge conflicts on this one

[g123k]

I think we should work on #2555 and dismiss this PR

[teolemon]

ok, closing 👍
sorry for the inconvenience @CyberWake