Entry field Enter does not always move to next field

[david-maw]

Description

On a screen with multiple entry fields the treatment of the enter key is inconsistent. What I've seen so far:

On Android, if ReturnType is set to Next the on screen key appearance changes to a 'Tab' icon and clicking it does nothing. If ReturnType="Done" the icon changes to an "Enter" icon and clicking it calls the Completed action. In neither case does it advance focus to the next field.

On Windows pressing the enter key calls OnCompleted whether ReturnType is set to Done or Next and the the focus switches to the next field if ReturnType is set to Next (and not Done) all of which seems correct.

Xamarin Forms acts like Windows (above) except that pressing enter in a field where ReturnType="Done" causes the field to be unfocused rather than focusing on the next field as Next would.

Steps to Reproduce

1. Unzip the project in Simple-Entry.zip
2. Compile and run the program on Android
3. Select the first field
4. Click on the on screen keyboard button to advance to the next field
5. Note that nothing happens (no call of OnCompleted, no change in focus)

Here's what you should see (the blue virtual key is the one you should click on):

Version with bug

Preview 14 (current)

Last version that worked well

Unknown/Other

Affected platforms

Android, I was not able test on other platforms

Affected platform versions

Android 11, Windows 10

Did you find any workaround?

No

Relevant log output

No response

[kristinx0211]

verified repro on Android 12 using above project.

[Michal-MK]

Just to add, the ReturnCommand is not executed reagdless the ReturnType used. (Android only, on Windows it does call the command.)

[Forestbrook]

Return key treatment found on 6.0.400-preview.22301.10:

ANDROID:

• ReturnType=Next: Tab-icon shown on return key. Nothing happens when the key is pressed, ReturnCommand and Completed event are NOT executed.
• ReturnType=Done: Check-icon shown on return key. When return key is pressed, Entry field has still focus, but ReturnCommand and Completed event ARE executed.

iOS

• ReturnType=Next: 'next' shown on return key. When return key is pressed, Entry field unfocused, ReturnCommand and Completed event ARE executed.
• ReturnType=Done: 'done' shown on return key. When return key is pressed, Entry field unfocused, ReturnCommand and Completed event ARE executed.

Windows (tested with external keyboard only)

• ReturnType=Next: When return key is pressed, focus to next Entry field, ReturnCommand and Completed event ARE executed.
• ReturnType=Done: When return key is pressed, Entry field has still focus, but ReturnCommand and Completed event ARE executed.

Preferred behavior:

• First of all, behavior should be consistent: the same on all platforms.
• ReturnType=Next: moving focus to next Entry field on all platforms would be nice, but it should be possible to overide this (I guess this is possible by setting the focus programmatically to another field in the Completed event - not tested).
• ReturnType=Done: unfocus the Entry field on all platforms and remove on-screen keyboard.

[david-maw]

Thanks @Forestbrook, very thorough. I'd just add that multi-line entry fields (text blocks) present an issue for "Next' behavior because it's often more convenient for the end user if they perform a new line function rather than switching to the next field. This does leave the problem of how to signal a switch to the next field using a soft keyboard, on Android at least, see issue #5730. I suspect in most cases it's easiest to use a gesture to do that, but one could imagine coding triple enter or something of that sort to mean the same thing.

[Forestbrook]

Thanks @Forestbrook, very thorough. I'd just add that multi-line entry fields (text blocks) present an issue for "Next' behavior because it's often more convenient for the end user if they perform a new line function rather than switching to the next field. This does leave the problem of how to signal a switch to the next field using a soft keyboard, on Android at least, see issue #5730. I suspect in most cases it's easiest to use a gesture to do that, but one could imagine coding triple enter or something of that sort to mean the same thing.

You can use the Editor control if you need multiple lines.

[david-maw]

@Forestbrook wrote "You can use the Editor control if you need multiple lines"

Sorry, I should have been clearer, I agree not only can you use an Editor for multi-line input, you should (issue #5730 does) so you make a good point that multi-line input is a non-issue for Entry fields. An Editor Control has the problem of how to signal end of entry as opposed to end of line, but it should not be an issue for an Entry field since they are the same thing.

[Kalyxt]

Is there workaround for this ? Its been two months without fix, how should I release app when keyboard doesn't hide automatically ?

[AbstractionsAs]

I'm struggling with this as well

[ghost]

We've moved this issue to the Backlog milestone. This means that it is not going to be worked on for the coming release. We will reassess the backlog following the current release and consider this item at that time. To learn more about our issue management process and to have better expectation regarding different types of issues you can read our Triage Process.

[dfcowan]

One workaround I've found is to set the IsEnabled property of the Entry to false. This causes the keyboard to disappear.