Multiple inline node selection not working intuitively
chrisdeeming opened this issue · comments
I will start by referencing a Tiptap issue I opened:
ueberdosis/tiptap#4526
I am able to reproduce the issue in ProseMirror:
https://github.com/ProseMirror/prosemirror/assets/2158514/b105a75e-2885-48a5-9da0-3e0d30b28ee1
In summary, node selection acts somewhat strangely in some cases.
The first issue demonstrated in the video, which is probably by design, is navigating through the content with arrow keys. Each arrow key press toggles between selecting the next image and moving the caret to the end of the image. As these are inline nodes, at least for this particular use case (emojis that are replaced with external images), a better behaviour would be for the arrow keys to toggle between moving the caret before the image, after the image, after the next image and so on.
The second issue you see is trying to Shift+LeftArrow to select the node(s). This definitely looks like a bug to me. It seems to be mostly when there are is no text before, after, or between the images.
An example of this being done "right" (IMHO) is Google Docs:
https://github.com/ProseMirror/prosemirror/assets/2158514/d6496c4b-1bb5-4ef5-89a0-7cc24b2dfef2
A few other editors have similar behaviour to that.
The other issue is when you click and drag to highlight/select the nodes. There's no visible indication that multiple nodes are highlighted. They are highlighted, because if you drag to highlight across two of the three nodes, a keypress on the keyboard will overwrite the images, but the lack of visual indication that they are highlighted feels like a UX issue.
Again, this is how it looks in Google Docs and some other editors:
Do we think this could be a bug and does anyone have a suggestion as to any workarounds that may be viable?
Many thanks
ProseMirror is not interfering with shift-arrow selection at all. This seems to simply be poor native browser behavior. Both Chrome and Firefox look like they work this way.
So then the question is whether prosemirror-view should try to override this when the node ahead of the cursor isn't editable, and what kind of complications could that pull in.
Thank you for such a quick reply.
Safari works that way too, FWIW.
I am a little biased, of course, as I'm being somewhat selfish in saying that, yes, overriding the behaviour would probably be ideal. Currently it isn't working how I'd expect in any browser.
That being said, after a quick test, it does seem the issue exists in most other editors too, at least for the Shift+Arrow case. Froala is roughly behaving the same way, some of the others are either getting in the way of the expected behaviour in other ways or suppressing it somehow. Redactor X is sort of the outlier as if you replicate the content by modifying the source code for the editor contents, it behaves as I'd expect (though there are other issues).
I'm not really very proficient in the nuts and bolts of ProseMirror at this point, but if you can foresee any workarounds I might be able to implement, any hints would be appreciated.
Finally, thank you for all that you've done. ProseMirror is a truly inspirational piece of work and it's obvious from your presence and proactivity on here and your forums that you are highly dedicated and I speak for everyone, whether they use ProseMirror directly, an implementation that utilises it, or Tiptap that we all appreciate what you've done and continue to do here. Thank you.
The way the native selection isn't visible across image nodes seems to be a Chrome thing. It seems to be caused by the draggable attribute. You can 'fix' it with a user-select: text style. It does it for all draggable elements, not just images.
I'm a little worried adding a catch-all style for this will have some unforeseen consequences (with CSS it can be hard to predict just what subtle nonsense it'll cause), but doing so seems to not break dragging, so it's probably still a good idea to have it.
Attached patches might improve this.
Thanks so much Marijn. I'm not currently clear on how I can test those changes in Tiptap but for now I think I'll just move on to the next thing!
I've tagged a version 1.32.1