Android keyboards caret jumping

[zimensky]

Caret doesn't jump over programmatically inserted symbols (like spaces, parentheses, etc) when using default Samsung and Sony keyboards.

Examples

Input sequence: 987654321
| means caret position.

Samsung keyboard

(|9  )
(8|9 )
(87|9)
(876|) 9
(876)| 59
(876) |459
(876) 3|45-9
(876) 32|4-59
(876) 321|-459

Expected 987654321
Actual 876321459 👎

Google keyboard

(9|  )
(98| )
(987|)
(987) 6|
(987) 65|
(987) 654|
(987) 654-3|
(987) 654-32|
(987) 654-321|

Expected 987654321
Actual 987654321 👍

Although the input mask works as expected when using Google keyboard (GBoard).

[catamphetamine]

You should always provide exact reproduction steps and the actual/expected outcome.
Speaking of Android, I'm not an owner of an Android phone so I guess that's out of my scope.
You could also test input-format because this library is based on it:
https://catamphetamine.github.io/input-format/

[zimensky]

Added examples to the issue desc.
Examples were tested on the demo page https://catamphetamine.github.io/input-format/

[catamphetamine]

Oh, I see.
Good examples.
I guess I can spot the issue: the first example seems to show the fact that the keyboard doesn't allow itself to be controlled (I mean caret positioning).
input-format uses input.setSelectionRange(position, position) to adjust the caret position correctly:

input-format/source/dom.js

Line 41 in 513e780

export function setCaretPosition(element, caret_position)

The first example though behaves like these "set caret position" function calls take no effect.
I think it could be related to the keyboard not allowing manual caret repositioning when editing a DOM <input/> or something like that.
I.e. I think it's a bug in Samsung keyboard.

The "Google keyboard" example on the other hand does allow manual caret repositioning and therefore works as expected.
And, of course, that's expected because Google is Google.
Samsung though is not Google and therefore they might not have tested their keyboard in such advanced use cases.

I guess this issue can be closed now since supporting non-standards compliant keyboards is out of the scope of the library.
Thx for the report anyway.

[catamphetamine]

So, the current state of the issue is: there seems to be an issue with some Samsung Android phones.
A workaround is to not use <ReactInput/> at all.
E.g. in react-phone-number-input developers can switch from <ReactInput/> to <BasicInput/> which doesn't have the Samsung Android bug:
catamphetamine/react-phone-number-input#75

[catamphetamine]

I was revisiting this issue and looked for similar issues in other libraries.
For example, there's text-mask library.
They've had exactly the same issue when the caret seemingly refused to be repositioned programmatically.
The symptoms were the same: whenever the caret passed through a non-digit character of a mask (a whitespace, a bracket, a dash, etc), it looked as if it placed itself one character before its correct position.
text-mask/text-mask#300
They seem to have found a basic fix for it: calling input.setSelectionRange() in a timeout rather than instantly for Android devices.
https://github.com/text-mask/text-mask/pull/400/files

Added such a workaround in this library too.
However, the reports on the fix aren't consistent in text-mask repo issues.
Some people say that such a fix is not required on new Samsung Android devices. Some people say that they can still observe the bug on some devices.
Whatever.