Describe the bug
When watching awareness updates from another user as they type at the end of a line, you can occasionally see the cursor jump down to the next line then back up to the text being written. See this YJS discussion thread on the exact issue, including a nice reproduction video: https://discuss.yjs.dev/t/cursor-jumping-to-next-line/483
When a user types a letter into the Quill editor, it triggers two events that are sent to and handled by _quillObserver
, first a 'selection-change'
event with source 'silent'
, and second a 'text-change'
event with source 'user'
. _quillObserver
will attempt to update the cursor awareness for both events, in that order, triggering the awareness.setLocalStateField
emitting an awareness event out to other users.
From here, it's a race condition for whether the first selection-change
update gets to a collaborative user and updates the awareness for the cursor on their screen BEFORE of AFTER the text-change
fully propogates. If it happens before, the cursor jumps forward a single index, making it twitch to the next line in the document, then the content of the document is updated to add the new character, and the selection is fixed.
To Reproduce
Steps to reproduce the behavior:
- Go to the y-quill demo in two different browsers (i.e. Chrome and Firefox).
- Continuously type on one browser at the end of a line of text.
- Observe the other browser's window and how the typing cursor is updated. As this is a race condition, you won't always see it, but it happens pretty often for me.
Expected behavior
The cursor that is typing stays smoothly attached to the end of the text that it is typing, without jumping forward in the document
Screenshots
See the YJS discussion thread linked in the description for a great example video
Environment Information
The environment for my Quill editor:
- Chrome, using a Quill editor within a Vue application
- YJS Versions:
- y-websockets: 1.4.3
- y-quill: 0.1.4
- y-protocols: 1.0.5
- Other versions:
- quill: 1.3.7
- quill-cursors: 3.1.2
Also works against the y-quill demo.
Suggested Solution
There doesn't seem to be a reason for the awareness update to fire for the'selection-change'
Quill event with a 'silent'
source. The awareness will only need to update correctly when the actual text change is also getting propogated over to other users, i.e. on the 'text-change'
event.
Not updating the awareness when the source is 'silent'
should correct the issue. PR to follow.