The wrong cursor position was inserted when clicking at the end of the paragraph

[sailxjx]

Describe the bug
When click the end of the paragraph, if the click area is in the editor, the position is right, if the area is in the padding area, the cursor will be inserted in the head of the paragraph, which I think need to be improved, because the user can't figure out where is the padding area.

I've recorded a video of this bug

Screen.Recording.2025-04-07.at.11.16.55.mov

To Reproduce
<clear steps to reproduce are super helpful! Best is to provide an online sandbox, click to create one>

Misc

• Node version:
• Package manager:
• Browser:
• I'm a sponsor and would appreciate if you could look into this sooner than later 💖

[NitanJana]

I think it's resolved in #1553

[nperez0111]

I think so too

[sailxjx]

The problem still exist, I've upgraded to v0.28. What I mean is to click on the padding area of the editor, not inside the editor. This area is visually indistinguishable from the inside of the editor, and the mouse behaves the same way. Please check my video, you can reproduce this issue on the official website. @nperez0111 @NitanJana

[NitanJana]

Yes @sailxjx , I could reproduce this on chrome as well as the example sandbox.

I was working with firefox/zen and this bug isn't present there. Maybe browser stylesheet issue?

[matthewlipski]

Interesting, the issue also isn't there on Safari so seems the root cause is how Chrome handles mouse clicks/selection changes in element padding (Chrome always seems to move the selection to the text start).

One way to at least make the behaviour at least consistent across browsers is to move the background & padding to the parent .bn-container element instead of the .bn-editor element. This makes clicking the padded area clear the selection instead of moving it, as the event is not captured by the editor itself.

Alternatively, we could just remove the padding on the right. It's there so that the editor appears centered while leaving space for the side menu, but it's a fairly minor thing.

Any thoughts on these 2 solutions? I think it's a bit overkill to override Chrome's default click/selection handling for this one case so I'd rather not go down that route.

Also indeed #1553 fixes a slightly different issue, as previously there was additional padding within blocks that would also cause this behaviour.

[nperez0111]

I would try to move around the padding so that it works, but not spend too much time on it. I'd say any resolution to thise should be CSS only and don't think it is a big deal if we can't find a resolution to it

[YousefED]

@matthewlipski could you maybe also check an older version of blocknote (i.e.: 1 or half year ago) and see if the problem still occurs there? I'm curious as I've only seen people mentioning this recently (could also be a browser regression ofc, or maybe just more people using BlockNote now)