Android keyboards caret jumping about input-format HOT 5 OPEN

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

from input-format.

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/

from input-format.

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:

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.

from input-format.

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

from input-format.

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.

from input-format.