text selection blink when cursor move over the inline-block

[zunsthy]

text selection blink when cursor from the paragraph begin to text, after add Decoration.widget zero-width space between cursor and inline-block node.

Decoration.widget(
  sel.head,
  () => document.createTextNode('\u200b'),
  { side: isParagraphEnd ? -1 : 1 }
)

2025-11-27.21.32.07.mov

it only happens on the structure:

| <node><text>

other stituations are not:

| <node><node><text>
<text><node> |
<node>| <node>

[marijnh]

Which browser does this happen in? How are you selecting? Shift-arrow? Mouse? Can you set up a small script that reproduces this, because I don't see it happen when I try to do what you are describing.

[Akarinx]

Which browser does this happen in? How are you selecting? Shift-arrow? Mouse? Can you set up a small script that reproduces this, because I don't see it happen when I try to do what you are describing.

@marijnh Hello, I'm using the mouse to select from the left side of the inline block, using chrome 142.0.7444.176

Here is the minimal demo:

[zunsthy]

@marijnh it can re-produce on macos chrome 142

demo page: https://4z4y.top/pm/bk-sel/

zero-width space code in here

[marijnh]

The issue appears to be that Chrome puts the start of the selection inside the widget (since it's the only text near the cursor), and then refuses to create a selection that starts in an uneditable node and ends in editable content. You can set a raw: true property on your widget config (next to relaxedSide: true) to leave the widget editable and sidestep this issue.

(I'd also recommend you either add a key to the widget config or make sure your widget drawing function is created only once and reused, or ProseMirror will keep redrawing the widget because it cannot tell that it's the same widget.)

[zunsthy]

The issue appears to be that Chrome puts the start of the selection inside the widget (since it's the only text near the cursor), and then refuses to create a selection that starts in an uneditable node and ends in editable content. You can set a raw: true property on your widget config (next to relaxedSide: true) to leave the widget editable and sidestep this issue.

set raw: true will break default edit behavior if input text from the position. i think i can't solve it. :(

[zunsthy]

@marijnh very thanks, and need more help.

if set raw: true, text input behavior is incorrect and the text disappears after cursor leaving.

2025-12-02.17.09.33.mov

after input text the dom like this:

it's the same behavior if not span wrapped.

[marijnh]

Oh indeed, that is annoying. Can you say a bit more about what this widget is trying to do? If you're just trying to create a barrier between the cursor and the node after, maybe try an <img> element without src, those are also invisible and treated like text, but don't have the issue that if you make them editable the cursor can go inside of them.

[zunsthy]

Can you say a bit more about what this widget is trying to do?

i try to fix cursor size by adding zwsp between cursor and inline-block element. but many attempts failed.

[rayzhi1130]

Windows Chorme 144.0.7559.59 also happend this issue!

Here is more infomation maybe you can use:
**when you let mouse focus at the right of the IMG and select to go left, it's OK, that mean this issue only happend when you select image from left to right, not right to left. **

[marijnh]

This issue has been moved to issue #1554 on the repository's new home.