Dropcursor bug with NodeViews?

1

We are replacing some top-level nodes (images, iframes etc) with a node view, in order to be able to show some UI (e.g. a close button).

However it seems like there’s an issue with the drop cursor plugin that calls .nodeDOM on the node which just returns null for node views, which then promptly crashes.

Is that a known issue? Should we work around that?

2

view.nodeDOM should work on nodes rendered with a node view too. Is this something that can be reproduced in a small script?

3

The docs do say that it would return null if the node is inside an opaque node view though:

May return null when the position doesn’t point in front of a node or if the node is inside an opaque node view.

4

True, but this position is coming from the cursor. Are you somehow setting the cursor position in a non-drawn node?

5

The way we reproduce is a bit more complicated since it might be some peculiarity of our schema, but it ends up like this:

  1. Have two editor instances side-by-side.
  2. One editor has an image in the content
  3. Drag the image from editor A to editor B
  4. Hover over editor B and see the dropcursor being rendered.
  5. If you hover over a paragraph, then you have 3 options: above/below/inside - inside as in, between characters, getting a vertical cursor.
  6. Make sure the drop cursor is in between characters, and release
  7. crash

There’s a few more complications:

  1. Our images can only appear within a figure, and neither figures nor images are inline content. We expected that the drop cursor shouldn’t even render in between characters but looking at the code, it doesn’t seem to know what actually is being hovered over the editor.
  2. The figure is the NodeView
  3. We have set both images and figures to be draggable, since if we made only the figure being draggable then the UX is sub-optimal (you have to first select the figure somehow to drag it). There are subtle differences.
  4. When dragging an external file, then the crash doesn’t happen. Not sure what the difference in the codepath is - but it seems like everything works as expected - if you drop in between characters, then the paragraph is split and the image ends up in the middle - I guess this is because we handle the drop event manually?
6

More info: The traceback is actually caused after the document is updated:

Screenshot 2022-10-25 at 15.42.42
Screenshot 2022-10-25 at 15.42.421228×274 69.7 KB

That is, the updateOverlay method as called by the update method after a transaction is dispatched and the updated state is set to the view (via .updateState)

And it gets even more weird in the debugger. At this point, the cursor should (in my head) be removed - the drop is over. before and after are both falsey (well, before is null and after seems to be not available, whatever that means. I’m not sure I’m using the watch expressions correctly.

Screenshot 2022-10-25 at 15.52.56
Screenshot 2022-10-25 at 15.52.562008×1192 482 KB

But indeed, if I understand correctly - the cursorPos is pointing to the image Node, which is indeed not rendered in the editor since it’s rendered by the NodeView (the figure), which is why nodeDOM returns null.

7

@marijn Getting a minimal repro is a bit tough, I hope the info I provided helps - if not, please let me know and I’ll dedicate some more time to it. Thanks for your attention!

8

I guess that cast there is dodgy regardless, and it should be okay to just not take that branch when null is returned. This patch does that.

9

Thanks, this does fix the bug. Much appreciated!

10

I also ran into this issue with the dropcursor + dragging an image that is rendered with a nodeview, but for me the issue is the subsequent getBoundingClientRect call below the one that was patched. I can try put some more effort into creating a minimal reproduction if wanted.