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 elm-discuss+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
