Set two inline item with contenteditable=false.
Then try to move the cursor in middle position. The cursor will display in the end of line, but the expect is to display in the middle position. Try to typing or trigger edit character it will add character in correct position, So I guess, it seems chromium’s bug.
I find the work around way, need use zero-width no-break space/ zero-width space and append it after or before every contenteditable=false element. But the space character will be mixed when pm trigger text input. It will bypass the pm selection system, and cause selection bug.
This is a known Chrome bug. Does Chrome 106 fix it? If so, that’d be great news.
It verified on my macbook. But I m working in low version chromium environments. Now, I’m stumbled in the old version of chromium environment. Did you have any idea to patch zero-width no-break space to hack the behaviour make cursor correct?
<img> without an
src attribute also seems to work, and causes less problems with ‘leaking’ of characters into the document text.
Yep, Prosemirror did handle this.
I’m digging the
prosemirror-view source code and find method named
addHackNode, It seems only add hack node for the last child of parent. In my case, there are many contenteditable=false elements, their will cause wrong cursor issue in chromium version less than 106.x. I think we need extend the
addHackNode to support wrapper around the every contenteditable=false element to make the cursor correct.
Adding such behavior at this point would be too disruptive. ProseMirror expects the authors of widgets to add their own hacks (in the form of internal zero-width spaces or CSS) to work around these Chrome issues.
Did you have any demo can extend widget. I know the decoration widget, but i don’t know which way is good for prosemirror.