Selection bugs out with custom MarkView

I am using a custom mark view that includes some interactive content (mainly a button). For some reason, moving selection backwards over it stops at the start of the mark view.

https://codesandbox.io/p/sandbox/prosemirror-mark-view-selection-ymwzst

https://github.com/TeemuKoivisto/prosemirror-mark-view-selection

Is there a trick to allow selection to pass through it normally? With NodeViews using contenteditable="false" helped but in this case it’s no use. I really wouldn’t want to use inline nodes with regular NodeViews since I have to handle manually all normal text join operations et cetera.

Interactive elements in marks is just not something the library supports. It’s rather problematic anyway, since marks can be arbitrary split by other marks, which would duplicate your elements weirdly.

Hmm I see. Damn. But you can order the marks in schema so that they are applied in a way that prevents splitting at the top level? So that split text with random marks is inside the contentDOM?

Also, you can technically add a mousedown event handler to a non-interactive element right? Hmm except when I now tried changing the button to a div or span the selection still doesn’t work.

The library is smart enough to override arrow cursor motion around uneditable nodes and widgets, but it cannot do this for random stuff you insert into marks.

Okay sure. It’s a bit confusing though that you can add the same DOM structure (as in my example) in the schema’s toDOM which allows moving selection backwards. However, the selection moves into the adjacent element (div/span) and adding contenteditable="false" again stops it from moving. So there’s a strict 1-1 parent-child mapping already with marks that can’t be overridden?

Not being able to use any interactive/multiple children for MarkViews makes them in my mind pretty niche. What I’d want is mark semantics (no need for haphazard position mapping & wrapping & lifting) with the possibility of having multiple children (an adjacent random div and contentDOM). Well, if it can’t be done it can’t be done.

Wait actually, it’s possible with Decoration.widget

https://codesandbox.io/p/sandbox/prosemirror-mark-view-selection-ymwzst

It’s not completely equal as now the button and the text lie adjacent as both are within the contentDOM. But from UI perspective it’s pretty much the same.

If this can be achieved with a decoration widget wouldn’t it possible to implement the same for MarkView? Seems pretty much what it’s meant to do. And marks are persistent vs. decorations so functionality-wise I don’t think they overlap. Don’t have to keep a big DecorationSet and constantly remap everything.