Mithril.js: 2-way binding on non-[input/textarea] contentEditable element sends the cursor to the front of the string

[CreaturesInUnitards]

_(I believe the title == the summary, in this case)_

Expected Behavior

Typing in a contentEditable context should behave like typing in any form field

Current Behavior

Using oninput: m.withAttr on a contentEditable sets the insertion point to the beginning of the string with each keystroke, resulting in the text entry being reversed.

Steps to Reproduce (for bugs)

flems

1. change the text
2. note the inverted results
3. shake your fist at the ceiling (optional)

Context

I was just trying to help someone on Gitter, and noticed this behavior. Personally, I've never encountered a scenario where a well-styled textarea wouldn't be superior to a contentEditable from a dev standpoint.

Your Environment

• m.version: 1.1.3
• Latest Safari, Chrome and Firefox
• Mac OS X 10.12.6

[pygy]

@CreaturesInUnitards thanks for the report, we'll investigate (the edit to your post was to pin the Mithril version)

[CreaturesInUnitards]

After looking deeper, the problem arises from specifying the relevant textContent in the view, either as the eponymous attribute, or as the child text node of the contentEditable element. This bug can be circumvented by only setting textContent in oncreate.

The fix for this bug IMHO may well be an entry in m.withAttr.md which illustrates the oncreate technique, specifically calling out the contentEditable context. I'm happy to provide if a code fix isn't coming.

workaround flems

[isiahmeadows]

This isn't easily avoidable, because the rendering algorithm doesn't know ahead of time what it's going to render. Also, another user workaround is to set e.redraw = false in the oninput handler, so it doesn't auto-redraw from there.

Finally, if you're using contenteditable, it's likely you will also need to manually patch the element yourself for other reasons (such as in a rich text editor component), so Mithril would do nothing but get in your way in that area.

So I'm leaning towards not fixing this on our end, because the added complexity isn't worth it, and the average use case is usually too low-level for vdom to be of much use.

[isiahmeadows]

To clarify, I'm referring to a code fix, not a docs fix.

[CreaturesInUnitards]

Understood completely, and agreed. Here's a riddle, if we decide to document this special case:

Is m.withAttr.md even the right place for this? The bug isn't related, but the use case in the wild almost certainly would be. I'd lean toward a caveat right after the 2-way binding example.

If you agree, I'll put together a PR for the docs tonight or tomorrow.

[isiahmeadows]

@CreaturesInUnitards

Probably best to add that (or something similar) as an example within the lifecycle hooks docs, and put in the "gotchas" section that you should avoid rendering any children (including text) to a contenteditable element.

As for m.withAttr.md, you could just link to the relevant gotcha section. It doesn't really matter either way whether you choose to use m.withAttr or not, since you can use m.withAttr("textContent", text => ...) without worry.

[CreaturesInUnitards]

@isiahmeadows

...put in the "gotchas" section...

Are you talking about "Avoid anti-patterns"? I can't find a proper "gotchas" section in lifecycle-methods.md

[isiahmeadows]

Er...yes, but I was referring to the wrong file. :-\

[CreaturesInUnitards]

Well thank god... I wasn't on your logic train _at all_ there... 😄

[isiahmeadows]

@CreaturesInUnitards It was renamed, and my brain forgot about that momentarily. I also was going off the top of my head, and misremembered thinking it was in lifecycle-methods.md, not hyperscript.md.

[CreaturesInUnitards]

You know, the more I look at this, the more I think adding anything about this _anywhere_ in the existing documentation is just going to be confusing, disorienting, insulting, or at the very least silly.

Maybe the best answer would be to create an actual, honest-to-goodness gotchas.md, and use it as a repository for all the weird little edge cases that aren't worth fixing in core. Kind of like a bizzarro @orbitbot's awesome-mithril, except flattened into a single document.

Thoughts?

[isiahmeadows]

@CreaturesInUnitards If you put together a PR with that, I'd definitely consider it. In particular, you could factor out most of the "Avoid anti-patterns" sections spread throughout the docs into that one file, so it's much easier to have it all in one place. It's also easier to link to from other files, and we could merge a few near-duplicates (like these two).

IIRC, we used to have a "Gotchas" section in one of the files (before v1 was released), but we renamed it because at the time, it only contained patterns to avoid, not also having things like this.