Preact: Bug: IE11, Edge and all Preact versions - textarea caret position

[atrolov]

Greetings! We use Preact on one project, he is very good with the file size, but we have recently found a nasty bug. In browsers IIE11 and Edge when editing in the middle message, of the cursor moves to the last character, demo http://jsfiddle.net/d2wtu9jz/2/

[developit]

Looks like a bug! Since Preact's debouncing isn't as tight async in IE, this triggers an issue where the state of the internal representation doesn't match the DOM's state. Here's a fiddle showing a manual fix (the third <textarea>) that preact should be doing internally:
http://jsfiddle.net/developit/jx865zrw/4/

Basically this line:
https://github.com/developit/preact/blob/master/src/vdom/diff.js#L252

should be changed to:

if (!(name in old) || attrs[name]!=(name==='value' || name==='checked' ? dom : old)[name]) {

I'll have to check the performance implications of this.

[atrolov]

Thank you, I took the version of Fiddle, as a temporary solution.

[cinaglia]

@developit It seems as though this issue made its way back. I'm running into the same issue in IE11 using [email protected]. I haven't yet had much success identifying the reason but wanted to give you a heads up in case you have any ideas.

[rmacklin]

I came across this bug as well (on preact v8.2.5) and chatted with @developit about it. I figured I'd repost my findings here for future readers who find this issue.

The first thing I did was see if the same bug happens in React (it doesn't).

I’m seeing a weird issue in Edge 16 (and earlier versions, also in IE11) that happens with preact but not with react. Here are two fiddles:
Preact:
http://jsfiddle.net/nydto11v/
React:
https://jsfiddle.net/xt0hxcwe/
If you type something into the textarea, then bring your cursor to the middle of what you’ve typed, and then keep typing, your cursor will jump to the end of the input as soon as you type one character (instead of remaining in place as you type). It doesn’t happen in other browsers, and it doesn’t seem to happen in the corresponding react version.

After some experimenting, I noticed that changing from <textarea value={value} /> to <textarea>{value}</textarea> fixed the issue in the preact version: http://jsfiddle.net/nydto11v/1/

I shared this "fix" (i.e. workaround) to @developit, and he pointed out that it wouldn't behave the same if you are setting value to something other than a string (e.g. <textarea>one<Foo /></textarea> where Foo returns a string), and also described the difference between the two under the hood:

// <textarea value="foo" />
element.value = 'foo'

// <textarea>foo</textarea>
if (element.firstChild.nodeType===3 && element.firstChild===element.lastChild) {
  element.firstChild.nodeValue = 'foo'
}
else {
  element.textContent = 'foo'
}

If you're always assigning to a string, the performance impact of this difference should be minimal.

Given that it works just fine in other browsers, I'm interested in coming up with a minimal repro that uses only vanilla DOM APIs (not preact), so that we could post a bug report for Edge. I haven't yet come up with a minimal repro outside of preact though.

_Update_: A better workaround is to replace <textarea value={value} /> with <textarea value={value}>{value}</textarea> (not just <textarea>{value}</textarea>), particularly if you are not destroying the textarea (removing it from the DOM) as soon as the form is submitted. If the textarea is going to remain in the DOM, keeping the value property in addition to setting the textContent is desirable in order to clear the text area after submission.