When starting to type shortly after synchronisation has started, cursor sometimes jumps to beginning of note as sync finishes

[jmbreuer]

Operating system

Linux

Joplin version

2.14.19

Desktop version info

Joplin 2.14.19 (prod, linux)

Client ID: 21e0babef7f2402fa0480a3ce8ba9bd1
Sync Version: 3
Profile Version: 46
Keychain Supported: No

Revision: 971c4e5

Backup: 1.4.0

Current behaviour

1. Typing in a note (draft of a complicated/conflict-associated eMail, i.e. in spurts and with lots of editing)
2. In one of the pauses, Joplin starts to sync (against WebDAV)
3. While the sync is running, start typing in the note again (appending at the end)
4. As the sync finishes, the cursor jumps to the beginning of the note mid-word and typing (inadvertently) continues there until user notices

Expected behaviour

Sync should not change the cursor position in a note that's actively being edited.

Logs

It doesn't appear to happen like this every time, I could not readily reproduce the problem after enabling debug logging. I'll leave it on for now and hope I'll catch a relevant log soon.

[jmbreuer]

Ah, I caught something in the log:

2024-03-22 10:26:43: Synchronizer: "Sync: updateRemote: local has changes: Note: (Local 6bb447d831004e2695a24bfe286ca2c0): (Remote 6bb447d831004e2695a24bfe286ca2c0.md)"
2024-03-22 10:26:43: FileApi: "put 6bb447d831004e2695a24bfe286ca2c0.md", "null"
2024-03-22 10:26:43: Synchronizer: "TaskQueue.stop: syncDownload: waiting for tasks to complete: 0"
2024-03-22 10:26:43: Synchronizer: "TaskQueue.stop: syncDownload: Done, waited for 0"
2024-03-22 10:26:43: FileApi: "delete locks/1_1_21e0babef7f2402fa0480a3ce8ba9bd1.json"
2024-03-22 10:26:43: Synchronizer: "Sync: finished: Synchronisation finished [1711099601932]"
2024-03-22 10:26:43: Synchronizer: "Operations completed: "
2024-03-22 10:26:43: Synchronizer: "updateRemote: 1"
2024-03-22 10:26:43: Synchronizer: "Total folders: 15"
2024-03-22 10:26:43: Synchronizer: "Total notes: 22"
2024-03-22 10:26:43: Synchronizer: "Total resources: 6"
2024-03-22 10:26:43: checkDisabledSyncItemsNotification: "No errors: Hiding notification"
2024-03-22 10:26:43: "Setting up recurrent sync with interval 300"
2024-03-22 10:26:43: "Sync has finished and note has never been changed - reloading it"
2024-03-22 10:26:44: "Saving note...", "{"id":"6bb447d831004e2695a24bfe286ca2c0","parent_id":"dd8e27ffa65f46af879915e691336dbe","title":"XXX","body":"YYY"}"
2024-03-22 10:26:44: "Scheduling sync operation...", "15000"
2024-03-22 10:26:44: "Saving note...", "{"id":"6bb447d831004e2695a24bfe286ca2c0","parent_id":"dd8e27ffa65f46af879915e691336dbe","title":"XXX","body":"YYY"}"
2024-03-22 10:26:44: "Scheduling sync operation...", "15000"
2024-03-22 10:26:44: "CommandService::execute:", "editor.undo", "[]"
2024-03-22 10:26:44: "CodeMirror: execCommand", "{"name":"editor.undo"}"
2024-03-22 10:26:45: "Saving note...", "{"id":"6bb447d831004e2695a24bfe286ca2c0","parent_id":"dd8e27ffa65f46af879915e691336dbe","title":"XXX","body":"YYY"}"
2024-03-22 10:26:45: "Scheduling sync operation...", "15000"

To me, this looks like the smoking gun:

2024-03-22 10:26:43: "Sync has finished and note has never been changed - reloading it"

This seems to be logged exactly when I experience the cursor jumping to the top when sync finishes.
It is not logged when there's concurrent sync and editing that behaves as expected, i.e. cursor remains at its document position.

I guess there's a (possibly concurrency/multi-threading) issue that causes a false positive for "note has never been changed", when, in fact, it has been / is being edited locally.

[github-actions]

Hey there, it looks like there has been no activity on this issue recently. Has the issue been fixed, or does it still require the community's attention? If you require support or are requesting an enhancement or feature then please create a topic on the Joplin forum. This issue may be closed if no further activity occurs. You may comment on the issue and I will leave it open. Thank you for your contributions.

[github-actions]

Closing this issue after a prolonged period of inactivity. If this issue is still present in the latest release, feel free to create a new issue with up-to-date information.