Skip to content

Question: Should local caret shift when remote user inserts text upstream in the same paragraph? #237

Description

@semimikoh

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):

  1. Open the same document in two browsers (User A and User B)
  2. As User B, click into a paragraph and place the caret in the middle of the text (right after a specific character)
  3. As User A, place the caret near the beginning of the same paragraph and type some characters
  4. 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>

Metadata

Metadata

Assignees

No one assigned

    Labels

    bugSomething isn't workingdocsRelated to wafflebase docs component

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions