Cursor issue with inline decoration setting contenteditable=false

[yyjhao]

Issue details

If a plugin makes an inline decoration that sets contenteditable=false attribute on a text node, and that text happens to be at the end of a line, the cursor will either not appear (in Firefox) or appear at the end of the div (in Safari). Chrome works, but if I additionally sets the opacity of the span as 0, then the cursor will not appear as well.

I imagine the same issue would have happened with any atomic nodes, but I noticed that there's already a fix for those here: https://github.com/ProseMirror/prosemirror-view/blob/cc72970db749f96a64b43d98ddd1738a59c9215c/src/viewdesc.js#L1146

I tried patching that by adding lastChild.outerDeco.some(d => d.type.attrs.contenteditable === "false" ) after the !(lastChild instanceof TextViewDesc) || check which seems to work - not only does it fix Safari and Firefox, on Chrome, it also makes the cursor appear again even if I set the opacity of the span to 0. My fix here is obviously quite hacky and I am not sure what the best way to fix here is.

Steps to reproduce

See below for an example. I made a simple plugin that creates an inline decoration from pos 0 to 1 and mark that as contenteditable=false

https://sheer-octagonal-alarm.glitch.me

Here's the project page: https://glitch.com/~sheer-octagonal-alarm

ProseMirror version

prosemirror-view 1.14.13

Affected platforms

• [x] Chrome (only if opacity = 0)
• [x] Firefox
• [x] Internet Explorer
• [x] Other (Safari)

Screenshots / Screencast (Optional)

[marijnh]

Setting inline content uneditable like this is not really supported—I expect there's a bunch of other things that will go wrong with that. What are you trying to achieve?

[marijnh]

Ah, I see, you're hiding textual emoji. That is indeed tricky to to. Does putting the image after the hidden text help with the cursor issues? (From the forum thread it sounds like you're putting it before, which would indeed confuse the end-of-line hack.)

[yyjhao]

Thanks! That works perfectly! I guess this bug still stands, but as you said this is a weird corner case that the editor doesn't need to support.