react-phone-number-input: Cursor doesn't keep up with typing on some Samsung Android phones

This reproducible on my Huawei running Android 6.0, and on Samsung S8+ phones. It happens with and without type="tel" in the <Phone> declaration, so I don’t think it’s related to this issue.

Set the country to “UK”, and type in “077915”. The input will contain “07791 5” (with a space) and the cursor will be positioned before the 5. Typing “67890” after this results in “07791 678905” instead of “07791 567890”.

It appears that on these devices that doing a complete onChange -> setState -> render cycle results in the cursor being positioned incorrectly. Calling setState in a setTimeout callback seems to fix it.

Here’s a pull request that seems to resolve the issue on my device: https://github.com/catamphetamine/react-phone-number-input/pull/74

About this issue

  • Original URL
  • State: closed
  • Created 7 years ago
  • Comments: 38 (21 by maintainers)

Commits related to this issue

Most upvoted comments

@Xopsy wow, thanks for thorough testing 👍 Ok then, it works.

Samsung seems to be a really big company that can afford writing its own everything: their own Android shell, their own Bixby, their own web browser… Looks like another Microsoft to me.

I added a smartCaret={false} property which sets inputComponent to <BasicInput/>. Use it instead of passing inputComponent={BasicInput} directly.

The demo has also been updated with an example of using the smartCaret={false} property.

Hey @catamphetamine, I did test right now with new version and still working fine in my samsung phone.

I’ve tested to different browsers from Samsung Galaxy S7 Edge:

Chrome ✅ Firefox ✅ Samsung Internet Browser

Even I have simulated with Xcode iPhone X (Safari Browser ✅) is working fine.

But for main mobile browser (Chrome and Safari) is working fine.

The problem only persist with that Samsung browser but this one is a minor issue, I haven’t tried other browsers. You have more here.

Also I leave a codePen. I did quickly test in there. Everyone can check it for their self.

So, I implemented the feature. See the linked commit for reference.

react-phone-number-input@latest

Usage:

import Phone from 'react-phone-number-input'

<Phone
  smartCaret={false}
  value={this.state.value}
  onChange={value => this.setState(value)}/>

smartCaret={false} caret is not as “smart” as the default one but still works good enough. When erasing or inserting digits in the middle of a phone number the caret usually jumps to the end: this is the expected behaviour and it’s the workaround for this Samsung Galaxy bug.

Internally smartCaret={false} sets inputComponent to <BasicInput/> instead of input-format’s <ReactInput/>. Use it instead of passing inputComponent={BasicInput} directly.

The demo has also been updated with an example of using the smartCaret={false} property.

Hi @catamphetamine , yes you can debug on physical mobile phone on android. You can use chrome, firefox, even with safari. After you give at your phone developer permissions and you can set up debugging with usb, you can use that features.

Firefox --> Firefox WebIDE Chrome --> chrome://inspect/#devices

Even if you can use adb or android studio for that purpose and into console view get different logs.

Only I leave this message because I saw your before answer. I didn’t try yet this component, but I was reading different threads about this issues. I don’t have to much time time but if possible I’d try to see this issue for myself.

But for my experience a delay something, it’s not usually good solution. Because of ent lop work in javascript

https://developer.mozilla.org/en-US/docs/Web/JavaScript/EventLoop

If you need to do something after setstate is called, or you use callback param or lifecycle into react components like https://reactjs.org/docs/react-component.html#componentdidupdate to do something with DOM.

Thanks 😉

Yes, pretty sure you can do that with Chrome debugging tools: chrome://inspect/#devices. I’ll post more here when I get a real Samsung device to test with.

@shivgarg5676 My guess is that this bug is unbeatable.

Yeah, that’s a tricky one. I imagine it could take up to infinity time to debug this one so make sure your head doesn’t blow ha ha.