Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

unwanted cursor jump with onInput #105

wintvelt opened this issue Dec 21, 2016 · 8 comments

unwanted cursor jump with onInput #105

wintvelt opened this issue Dec 21, 2016 · 8 comments


Copy link

When the value of an input field is managed in the model, like so:

input [ onInput HandleInput, value model.value ] []

Then fast typing will cause the cursor to jump from the current position to the end of the input field.
SSCE here

This "bug" has led to various patterns, such as using defaultValue instead of value. But that particular solution is "leaky". If the input field is reused by VDOM, its internal value will also be reused. In a specific scenario (example here) this causes contents of a password field to show.

Copy link

Thanks for the issue! Make sure it satisfies this checklist. My human colleagues will appreciate it!

Here is what to expect next, and if anyone wants to comment, keep these things in mind.

Copy link


As I understand it, one solution to both of those issues would be to make onInput synchronously trigger update and then view and then a re-render to the real DOM, bypassing the current requestAnimationFrame batching that improves performance in the general case.

Not saying that's a good road to go down, but it's my understanding of how React gets value to "Just Work."

Copy link

OvermindDL1 commented Jan 6, 2017

What I do is set a flag on the model to 're-render' a given textarea while also giving a command/task to send another 'after' message. The view then sets the text via value when the flag is set, else it does not set a value at all. On the callback of the given message then it un-sets the flag on the model to 're-render' a given textarea. Hacky, but it works, and it can only jump the cursor when I am explicitly setting the value and never any other time. Quite a hack though...

(Technically what I am doing right now is removing and re-adding the textarea to the DOM in actuality to work around other bugs, blehg).

Copy link

TreyE commented Jan 19, 2017

I face a similar issue for my 'masked input' controls. What I do is track the cursor location and then execute a command after the draw using a port. It's a very ugly way to do it.

I don't mind having to manually track the location of the cursor in my model - since I'm altering input as I get it that makes sense - I just wish there were a property or something on the input control I could set that would place the cursor at the right location when my input is rendered.

I feel like this issue is really the main blocker for building masked input controls intuitively in Elm.

Copy link

I think I'm seeing a related issue to this. Most of the time, my input fields work fine. But occasionally, I seem to get "double inputs" where the letters get doubled up. I've had users report it and sporadically seen it myself, but I've had trouble getting it to reproduce.

Copy link

charukiewicz commented Jun 13, 2017

I would like to confirm this issue. This is happening in both our little 400 LoC internal tool and our very large 20k LoC production feature, so the size of the Elm app seems to have no effect on the problem (my initial assumption was that this could be fixed using more Html.lazy, but that does not seem the case).


I managed to recreate the issue based off of the code in #42:

Copy link

zwilias commented Jun 19, 2017

As a possible workaround; one could use defaultValue to set the initial value, onInput to sync it to the model, and a Html.Keyed node so values can be reset. That would look something like this:

Copy link

evancz commented Jul 7, 2017

Tracking in Thank you for the report!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
None yet
None yet

No branches or pull requests

9 participants