What happened:
In the collaborative document editor, when User A inserts text before User B's caret position within the same paragraph, User B's caret does not shift along with the growing text. It stays at the same absolute offset, so it visually appears at the same screen position while the surrounding text moves to the right. As a result, User B's caret no longer points to the character it was originally anchored to.
I'm not sure whether this is a bug or an intentional design choice, so I'd like to confirm.
What you expected to happen:
I expected User B's caret to remain anchored to the same logical position (e.g., still right after the character it was placed after), shifting its visual position to the right as User A's text is inserted upstream. This matches how Google Docs and Notion behave.
Example:
- Initial paragraph:
Hello world
- User B's caret is placed right after
wo (between wo and rld)
- User A types
Hi at the beginning of the same paragraph
- Expected: paragraph becomes
Hi Hello world, User B's caret is still right after wo
- Actual: paragraph becomes
Hi Hello world, but User B's caret remains at the same absolute offset, now pointing somewhere inside Hello instead of after wo
How to reproduce it (as minimally and precisely as possible):
- Open the same document in two browsers (User A and User B)
- As User B, click into a paragraph and place the caret in the middle of the text (right after a specific character)
- As User A, place the caret near the beginning of the same paragraph and type some characters
- Observe User B's caret position — it stays at the same visual location instead of shifting right along with the inserted text
Anything else we need to know?:
There is a valid design argument for keeping an idle caret visually stable to avoid disorienting the user during remote edits, so this might be intentional. A couple of questions:
- Is the current behavior intentional?
- Or is anchoring the caret to a relative position (e.g., Yorkie's path-based position / IndexTree path) planned but not yet implemented?
Happy to file a proper bug report or contribute a fix if this turns out to be unintended.
Environment:
- Operating system: <e.g. macOS 14.5>
- Browser and version: <e.g. Chrome 138.0.7204.97>
What happened:
In the collaborative document editor, when User A inserts text before User B's caret position within the same paragraph, User B's caret does not shift along with the growing text. It stays at the same absolute offset, so it visually appears at the same screen position while the surrounding text moves to the right. As a result, User B's caret no longer points to the character it was originally anchored to.
I'm not sure whether this is a bug or an intentional design choice, so I'd like to confirm.
What you expected to happen:
I expected User B's caret to remain anchored to the same logical position (e.g., still right after the character it was placed after), shifting its visual position to the right as User A's text is inserted upstream. This matches how Google Docs and Notion behave.
Example:
Hello worldwo(betweenwoandrld)Hiat the beginning of the same paragraphHi Hello world, User B's caret is still right afterwoHi Hello world, but User B's caret remains at the same absolute offset, now pointing somewhere insideHelloinstead of afterwoHow to reproduce it (as minimally and precisely as possible):
Anything else we need to know?:
There is a valid design argument for keeping an idle caret visually stable to avoid disorienting the user during remote edits, so this might be intentional. A couple of questions:
Happy to file a proper bug report or contribute a fix if this turns out to be unintended.
Environment: