Moving selection with arrows behaves weirdly with NodeView

It seems NodeViews can cause all kinds of little problems with selections.

Here’s one I am not sure how to handle:

https://github.com/TeemuKoivisto/prosemirror-node-view-gutters/tree/main

Basically, adding gutters causes the selection, when moved at the start of block with arrow up, to not go directly upwards but to the right end of the upper block node. If I remove the left gutter it’s fixed but moving downwards from the end of block misbehaves. With only right gutter the arrow moving works, just that sometimes the caret flickers into the NodeView.

That might be fixed in part with Prevent the caret from moving outside a custom nodeview for arrow keys - #4 by marijn but I do not want to prevent the arrow moves, just keep the default behavior.

That’s a lot more code than I’m willing to read, and I’m not clear on what you mean by ‘gutter’ here. If you can reduce this to a small, self-contained example I could take a look.

Here’s a sandbox inspiring-tamas-z237dd - CodeSandbox

I can’t get the thing you show in the movie to happen in that demo. It might help to provide a textual description of what you’re doing and tell me what browser and platform you’re using.

Ah, it’s a Chrome bug. It doesn’t occur in Firefox. I updated my Chrome version to latest (118) and now it behaves differently again.

Before:

  1. Insert two paragraphs with text
  2. Go to start of second paragraph
  3. Press arrow up
  4. Goes to end of first paragraph instead of start

Now (with latest Chrome):

  1. Insert two paragraphs with text
  2. Go to start of second paragraph
  3. Press arrow left
  4. Nothing happens

Same with end of a paragraph and arrow right. Very strange. Works perfectly with Firefox. I’m using macOS 12 with arm64

I can see that happening now. But with this kind of thing, where your custom DOM structure causes the browser’s cursor motion to fall apart, the library does not try to detect and handle every possible such thing (the set of possible DOM structures and corresponding browser mess-ups is infinite, it’d be too much). So you’ll probably want to either change your DOM structure to avoid the bug, or register a custom key handler that detects this situation and moves the selection the way it should move.