Race condition in textareas?

[Esteban Manchado Velázquez]

Hi,

I have a strange, intermittent issue with textareas. It mostly seems to happen in mobile browsers. The issue is that, when editing text *in the middle* of a textarea, as opposed to adding to the end, sometimes the cursor jumps to the end. I assume it's some kind of re-creation of the textarea DOM element.

I have made a simple application with a textarea but that DOES seem to work fine... so I'm wondering if the problem happens because my application is bigger, and I have "subapplications" that use App.map for messages and so on.

Has anyone seen that before? Is it something stupid I'm doing, a bug in Elm, ...? I can make the full source code available if that'll help.

[Alexandre Galays]

Most VDOM libs have a hack in place to prevent the value of an input/textarea from being written again if it didn't change, as it resets the cursor in some browsers.

Could be that.

Example in snabbdom: https://github.com/snabbdom/snabbdom/blob/master/src/modules/props.ts#L21

[Wil C]

I just ran into this problem. And the work around was pretty simple, and mentioned in a message in this group a while back.

          textarea [

            property "defaultValue" (Json.Encode.string model.body)

          , onInput UpdateBody

          , rows (model.cursorAperture * 2)

          , id "edit-glass"

          , class "form-control"] []

        ]

I used defaultValue instead of value. I think the textarea and the various frameworks fight each other when 'value' is used, so you get the jumpiness going on. I think it's because Elm is keyed off of 'value' for updates. This way, the textarea maintains its own state, and when it changes, it doesn't trigger a re-render from Elm for the textarea itself.

[John Watson]

Thanks very much, Wil. I was suffering from this and this change fixes it I think.

[John Watson]

Maybe I spoke slightly too soon.  I have an application where the 'model' which is visible to the text area can also be modified by buttons and other input widgets.  After making the change in the text area from value to defaultValue, things continue to work as expected with Chrome and Opera, but no longer with Firefox.  What happens is that things go well for a bit, but after using the other input widgets, after a little while, the text area 'freezes' and no longer seems to accept updates from the model.

[Esteban Manchado Velázquez]

Thanks a lot, I'll give it a try :-)

But, that implies that Elm has a bug and this is just a workaround, right? The proper solution would be passing the model value as "value", not "defaultValue", to the textarea...

[John Watson]

My code seems to fail in Firefox immediately a slider is operated by the user.  After reading this discussion on shady dom, I'm wondering whether the issue is that Firefox has no implementation of shadow dom whilst both Chrome and Opera do.  Surely this is no coincidence - can anyone enlighten me?

[OvermindDL1]

Elm does not use Shady DOM nor Shadow DOM, so that would be unrelated unless you are using the Shady or Shadow DOM's outside of elm but within the elm application.

For note, updating the defaultValue will only update the textarea if the textarea is destroyed and recreated, updating the value will update it in real time but that means that you can also desync from a user typing if incoming messages overwrite each other if the user types too fast.  I tended to only set the 'value' when I wanted to force overwrite and just did not set it at all for the rest of the messages to work around it.

[John Watson]

Many thanks - very useful.  I'm not entirely sure how best to achieve this - I need to spend a bit of time investigating.

[John Watson]

In case anyone's still interested, I sorted out the problem I think.  defaultValue is working absolutely fine.  The problem appears to be that there is a difference between the way Firefox on the one hand and Chrome and Safari on the other require you to get input from the slider.  The former requires "on input" whilst the latter requires "on change" - see http://stackoverflow.com/questions/18544890/onchange-event-on-input-type-range-is-not-triggering-in-firefox-while-dragging. Fixed simply by adding both.