"Empty text nodes are not allowed" when trying to move a decorated section of text into a slice using ReplaceAroundStep

[Sarah]

Hi,

I have an inline node type that we want to wrap text after a specific operation triggered by the user. At the moment I'm doing this using a ReplaceAroundStep that moves the selected region directly into a new stub slice of the node we want.

The problem arises if there's an inline decoration over the bounds of the area we're trying to move into the slice. The issue appears to be that we:

• trigger the replacearound step
• the decoration is updated and mapped through the step by its controlling plugin state
• the editor updates and iterDeco goes through the nodes.

What I think is happening is that iterDeco on the outer doc node gets confused and doesn't increment decorationIndex when it's moving past the newly inserted inline node as the decorations are now entirely inside its bounds. As this index isn't incremented at all, the next text node after this new inline node tries to cut itself as it thinks that this deco (which has been passed) ought to be taken into account.

This means that https://github.com/ProseMirror/prosemirror-view/blame/master/src/viewdesc.ts#L1448
is called with a negative value as the second argument, which prosemirror rejects as it would create an empty text node.

Sandbox here to reproduce: https://codesandbox.io/s/interesting-parm-sj792m?file=/src/editor/index.jsx
Click the button to insert an inline node at the position that's got a decoration and observe the error thrown.

Perhaps this is a result of poor practice of us using ReplaceAroundStep or maybe we're mapping decorations in a bad way.
It looks like it might be fixable by changing the condition: https://github.com/ProseMirror/prosemirror-view/blame/master/src/viewdesc.ts#L1409

to instead use

locals[decoIndex].to <= offset

so that the decoIndex can be incremented to skip decorations that ended before the current offset we're working with.

Keen to hear your thoughts

[Marijn Haverbeke]

You were right that this was a bug in the iterDeco logic. Attached patch should address it.

[Sarah]

Thank you so much for your quick response and fix! Your responsiveness to bug reports is one of the reasons I enjoy working with this library so much.