{"action":"created","issue":{"url":"https://api.github.com/repos/lhorie/mithril.js/issues/701","labels_url":"https://api.github.com/repos/lhorie/mithril.js/issues/701/labels{/name}","comments_url":"https://api.github.com/repos/lhorie/mithril.js/issues/701/comments","events_url":"https://api.github.com/repos/lhorie/mithril.js/issues/701/events","html_url":"https://github.com/lhorie/mithril.js/issues/701","id":91966324,"number":701,"title":"Mithril 0.2.0 textarea not updating when expected if not storing its value to a model","user":{"login":"pdfernhout","id":379347,"avatar_url":"https://avatars.githubusercontent.com/u/379347?v=3","gravatar_id":"","url":"https://api.github.com/users/pdfernhout","html_url":"https://github.com/pdfernhout","followers_url":"https://api.github.com/users/pdfernhout/followers","following_url":"https://api.github.com/users/pdfernhout/following{/other_user}","gists_url":"https://api.github.com/users/pdfernhout/gists{/gist_id}","starred_url":"https://api.github.com/users/pdfernhout/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/pdfernhout/subscriptions","organizations_url":"https://api.github.com/users/pdfernhout/orgs","repos_url":"https://api.github.com/users/pdfernhout/repos","events_url":"https://api.github.com/users/pdfernhout/events{/privacy}","received_events_url":"https://api.github.com/users/pdfernhout/received_events","type":"User","site_admin":false},"labels":[],"state":"open","locked":false,"assignee":null,"milestone":null,"comments":4,"created_at":"2015-06-30T03:14:25Z","updated_at":"2015-07-11T16:10:20Z","closed_at":null,"body":"This is essentially to reopen Issue #95 by ldimi. Here is a JSFiddle that demonstrates an issue with textarea updating: http://jsfiddle.net/pdfernhout/wv46fkg0/\r\n\r\nThe test seems to show that a textarea is not being updated to overwrite its user-entered contents unless the related model value itself changes (which then causes Mithril to decide the textarea's value is out-of-date). This means the textarea could potentially get out of step with what is in the model. It seems possible that textareas only work OK in most in-practice cases because their models are constantly changing to different values as they are edited and store those changes into the model? Granted, the behavior demonstrated in the fiddle may not be a common situation because the behavior will only manifest itself if an application does not respond to every change in a textarea's contents in a way that updates the value of the textarea. However, as the fiddle shows, a regular text input works as one might expect, so there is an inconsistency here.\r\n\r\nIn the application I'm working on, this issue manifested when initially setting a item-detail textarea to an empty string via value and then manually entered text into the textarea via the browser. The application code (intentionally) discarded the change because an associated display item was not yet selected. So, the textarea's internal value was not being updated by the application in the view method as the textarea's text was changed by the user, as would otherwise normally be the case. (Yes, the textarea should ideally be disabled if the data is not available -- I just noticed this issue while working towards that ideal.) The issue became apparent when a subsequent change in the data model by setting value on the textarea again to an empty string for an available data item was not reflected in the application GUI. I think this is because Mithril 0.2.0 apparently decided that the textarea must still be blank because its value was originally set that way (despite its actual contents being changed by the user). When I replaced the textarea with a text input, the application worked as I initially expected, with the displayed value in the input cleared when selecting an available item.\r\n\r\nThe solution is probably similar to what ldimi outlined. In setAttributes, the test:\r\n\r\n    else if (attrName === \"value\" && tag === \"input\" && node.value != dataAttr) {\r\n\r\nshould probably be:\r\n\r\n      else if (attrName === \"value\" && (tag === \"input\" || tag === \"textarea\") && node.value != dataAttr) {\r\n\r\nI say \"probably\" because since a textarea can take internal text elements, as well as be set by \"value\", I'm not sure about any other implications in that other case. I tested the change locally and with the change the textarea updated as I expected (back to empty when tabbing out caused a redraw). But I was only setting the value, not the internal text components. Also, I'm not sure what the performance implications are. I'd agree this is an edge case, since most applications would presumably have a valid model to store data in that closely tracks the textarea's current contents, and so Mithril 0.2.0's current updating strategy might be good enough in that case. However, it is also an edge case that took hours of troubleshooting and research to isolate down to this test case and this understanding -- so ideally others could be spared that, since this edge case may be a common situation while developing an app incrementally, even if a finished app may avoid it. Still, on the plus side, I know a bit more about Mithril internals now from debugging this. :-) And a big advantage of Mithril is that it is much easier to debug than many other GUI frameworks.\r\n\r\nAlso, I wonder if this issue is to any extent a regression error introduce by removing the check in setAttributes of: \"|| node === window.document.activeElement\" which was present in Mithril 0.1.14? Presumably that might have forced the update of a recently-used textarea's value when it was the current widget? I'm not saying to go back to that approach, just that textarea updating might have worked differently back then."},"comment":{"url":"https://api.github.com/repos/lhorie/mithril.js/issues/comments/120636233","html_url":"https://github.com/lhorie/mithril.js/issues/701#issuecomment-120636233","issue_url":"https://api.github.com/repos/lhorie/mithril.js/issues/701","id":120636233,"user":{"login":"pelonpelon","id":254146,"avatar_url":"https://avatars.githubusercontent.com/u/254146?v=3","gravatar_id":"","url":"https://api.github.com/users/pelonpelon","html_url":"https://github.com/pelonpelon","followers_url":"https://api.github.com/users/pelonpelon/followers","following_url":"https://api.github.com/users/pelonpelon/following{/other_user}","gists_url":"https://api.github.com/users/pelonpelon/gists{/gist_id}","starred_url":"https://api.github.com/users/pelonpelon/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/pelonpelon/subscriptions","organizations_url":"https://api.github.com/users/pelonpelon/orgs","repos_url":"https://api.github.com/users/pelonpelon/repos","events_url":"https://api.github.com/users/pelonpelon/events{/privacy}","received_events_url":"https://api.github.com/users/pelonpelon/received_events","type":"User","site_admin":false},"created_at":"2015-07-11T16:10:20Z","updated_at":"2015-07-11T16:10:20Z","body":"@pdfernhout Maybe you should close this issue with a forwarding link to the other discussion."}}