Remove current cursor selection?

1

Hi,

I am rendering a custom node that displays an input. When the node is inserted with tr.insert, the current selection.$cursor is automatically placed afterwards the node.

But it raises UX issues, as it displays another cursor after the caret that is in the input, deletion at the beginning of the line will remove the node instead of deleting a character in the input etc.

image

I’ve tried to select the newly created node, but it’s not what I want either, as typing some text will remove the node and replace it with the typed text.

image

Another thing I’ve tried is having a command that simply returns true when such a node is detected in the relevant position, in order to skip other inputrules (eg for backspace). That doesn’t work because returning true in an inputrule seems to swallow the event, so nothing is deleted in the input.

Ideally, I would like to have no selection, neither a $cursor or the current Node, so that all behaviour relying on the current selection would be disabled. Is that doable?

Perhaps I should craft a new kind of “DummySelection”?

2

This sounds like what you want is to move the focus to the input, rather than messing with the selection in the ProseMirror view.

3

The input does have the focus but prosemirror keymaps seems to have the priority over it :confused: Otherwise it would have worked out of the box I think

You can see the caret (the browser one, the blue thing matches the current selection.$cursor)in the first screenshot confirming it has the focus

Example if I press enter: image

The input keeps the focus but it inserts line below at the cursor position

I’ll try to swallow “keydown” events in the input maybe

1 Like
4

In that case, it sounds like you need to use stopEvent on your node view to tell ProseMirror which events aren’t meant for it.

1 Like
5

Exactly what I needed! I think the issue is that stopping the “input” (directly from the event handler) was not enough as all related events must also be stopped (“keydown” etc.), so a stopEvent that returns true is perfect.