[elm-discuss] Re: Race condition in textareas?

[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.

On Wednesday, 7 December 2016 18:26:16 UTC, John Watson wrote:
>
> Many thanks - very useful.  I'm not entirely sure how best to achieve this 
> - I need to spend a bit of time investigating.
>
> On Wednesday, 7 December 2016 15:16:25 UTC, OvermindDL1 wrote:
>>
>> 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.
>>
>>
>> On Wednesday, December 7, 2016 at 2:50:59 AM UTC-7, John Watson wrote:
>>>
>>> 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?
>>>
>>> On Monday, 5 December 2016 17:09:06 UTC, John Watson wrote:

 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.

 On Monday, 5 December 2016 15:24:48 UTC, John Watson wrote:
>
> Thanks very much, Wil. I was suffering from this and this change fixes 
> it I think.
>
> On Monday, 5 December 2016 15:08:22 UTC, Wil C wrote:
>>
>> 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.
>>
>> On Saturday, December 3, 2016 at 11:08:38 AM UTC-8, Esteban Manchado 
>> Velázquez wrote:
>>>
>>> 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.
>>>
>>

-- 
You received this message because you are subscribed to the Google Groups "Elm 
Discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to elm-discuss+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[elm-discuss] Re: Race condition in textareas?

[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.

On Wednesday, 7 December 2016 15:16:25 UTC, OvermindDL1 wrote:
>
> 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.
>
>
> On Wednesday, December 7, 2016 at 2:50:59 AM UTC-7, John Watson wrote:
>>
>> 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?
>>
>> On Monday, 5 December 2016 17:09:06 UTC, John Watson wrote:
>>>
>>> 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.
>>>
>>> On Monday, 5 December 2016 15:24:48 UTC, John Watson wrote:

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

 On Monday, 5 December 2016 15:08:22 UTC, Wil C wrote:
>
> 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.
>
> On Saturday, December 3, 2016 at 11:08:38 AM UTC-8, Esteban Manchado 
> Velázquez wrote:
>>
>> 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.
>>
>

-- 
You received this message because you are subscribed to the Google Groups "Elm 
Discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to elm-discuss+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[elm-discuss] Re: Race condition in textareas?

[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.


On Wednesday, December 7, 2016 at 2:50:59 AM UTC-7, John Watson wrote:
>
> 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?
>
> On Monday, 5 December 2016 17:09:06 UTC, John Watson wrote:
>>
>> 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.
>>
>> On Monday, 5 December 2016 15:24:48 UTC, John Watson wrote:
>>>
>>> Thanks very much, Wil. I was suffering from this and this change fixes 
>>> it I think.
>>>
>>> On Monday, 5 December 2016 15:08:22 UTC, Wil C wrote:

 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.

 On Saturday, December 3, 2016 at 11:08:38 AM UTC-8, Esteban Manchado 
 Velázquez wrote:
>
> 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.
>


-- 
You received this message because you are subscribed to the Google Groups "Elm 
Discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to elm-discuss+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[elm-discuss] Re: Race condition in textareas?

[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?

On Monday, 5 December 2016 17:09:06 UTC, John Watson wrote:
>
> 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.
>
> On Monday, 5 December 2016 15:24:48 UTC, John Watson wrote:
>>
>> Thanks very much, Wil. I was suffering from this and this change fixes it 
>> I think.
>>
>> On Monday, 5 December 2016 15:08:22 UTC, Wil C wrote:
>>>
>>> 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.
>>>
>>> On Saturday, December 3, 2016 at 11:08:38 AM UTC-8, Esteban Manchado 
>>> Velázquez wrote:

 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.

>>>

-- 
You received this message because you are subscribed to the Google Groups "Elm 
Discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to elm-discuss+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[elm-discuss] Re: Race condition in textareas?

[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...


El lunes, 5 de diciembre de 2016, 16:08:22 (UTC+1), Wil C escribió:
>
> 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.
>
> On Saturday, December 3, 2016 at 11:08:38 AM UTC-8, Esteban Manchado 
> Velázquez wrote:
>>
>> 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.
>>
>

-- 
You received this message because you are subscribed to the Google Groups "Elm 
Discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to elm-discuss+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[elm-discuss] Re: Race condition in textareas?

[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.

On Monday, 5 December 2016 15:24:48 UTC, John Watson wrote:
>
> Thanks very much, Wil. I was suffering from this and this change fixes it 
> I think.
>
> On Monday, 5 December 2016 15:08:22 UTC, Wil C wrote:
>>
>> 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.
>>
>> On Saturday, December 3, 2016 at 11:08:38 AM UTC-8, Esteban Manchado 
>> Velázquez wrote:
>>>
>>> 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.
>>>
>>

-- 
You received this message because you are subscribed to the Google Groups "Elm 
Discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to elm-discuss+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[elm-discuss] Re: Race condition in textareas?

[John Watson]

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

On Monday, 5 December 2016 15:08:22 UTC, Wil C wrote:
>
> 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.
>
> On Saturday, December 3, 2016 at 11:08:38 AM UTC-8, Esteban Manchado 
> Velázquez wrote:
>>
>> 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.
>>
>

-- 
You received this message because you are subscribed to the Google Groups "Elm 
Discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to elm-discuss+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[elm-discuss] Re: Race condition in textareas?

[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.

On Saturday, December 3, 2016 at 11:08:38 AM UTC-8, Esteban Manchado 
Velázquez wrote:
>
> 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.
>

-- 
You received this message because you are subscribed to the Google Groups "Elm 
Discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to elm-discuss+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[elm-discuss] Re: Race condition in textareas?

[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

On Saturday, December 3, 2016 at 8:08:38 PM UTC+1, Esteban Manchado 
Velázquez wrote:
>
> 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.
>

-- 
You received this message because you are subscribed to the Google Groups "Elm 
Discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to elm-discuss+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.