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 >> <https://groups.google.com/forum/#!topic/elm-dev/TvnVOpz3l0Q> on shady >> dom, I'm wondering whether the issue is that Firefox has no >> implementation <http://caniuse.com/#search=shadow%20DOM>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 [email protected]. For more options, visit https://groups.google.com/d/optout.
