Note list scrolls to the bottom when a plugin creates a note and opens it with openNote (depends on the debounced NOTE_SORT)

Operating system

Windows

Joplin version

3.7.16

Desktop version info

Joplin 3.7.16 (prod, win32); also present in 3.6.x. Not present in 3.5.x. Reproduced with the Templates plugin 3.0.0 (joplin.plugin.templates), sort order "updated date, descending", notebook with ~1700 notes.

Current behaviour

1. Open a notebook with enough notes for the note list to be scrollable.
2. Create a note from a template. The plugin does the equivalent of: const note = await joplin.data.post(['notes'], null, { title, body, parent_id }); await joplin.commands.execute('openNote', note.id);
3. Repeat two or three times in quick succession (less than 10 seconds apart).

The note list scrolls all the way to the bottom (oldest notes). The new note is at the top a moment later, but the scroll position stays at the bottom, so you have to scroll back up every time.

Whether it happens is timing-dependent: the first note created after a pause of more than ten seconds usually works, and the ones created shortly after do not. This makes it look intermittent, which is why it is easy to misread as a random glitch.

Expected behaviour

The note list stays on the newly created note, which sorts to the top as it does when using the app's own "New note" button.

Logs

Instrumented trace from a running 3.7.16 (wrapped store.dispatch, plus a hook on the note list's scrollTop setter), four notes created from a template in a row. selIdx is the index of the selected note at that moment, sinceSort is Date.now() - noteListLastSortTime:

1 sinceSort was 335 s, so the sort ran immediately -> works

308209 NOTE_SORT n=1692 selIdx=1 sinceSort=1 308223 FOLDER_AND_NOTE_SELECT n=1692 selIdx=0 sinceSort=15 scroll=0 308230 >>> scrollTop := 0

2 sinceSort 4035 ms, so the sort was deferred -> broken

312458 FOLDER_AND_NOTE_SELECT n=1693 selIdx=1692 sinceSort=4038 scroll=0 312465 >>> scrollTop := 56340 312561 NOTE_UPDATE_ALL n=1693 selIdx=0 scroll=56340 314450 NOTE_SORT n=1693 selIdx=0 sinceSort=0 scroll=56340

3 sinceSort 4320 ms -> broken, same pattern

318774 FOLDER_AND_NOTE_SELECT n=1694 selIdx=1693 sinceSort=4324 scroll=0 318781 >>> scrollTop := 56374 320767 NOTE_SORT n=1694 selIdx=0 sinceSort=0 scroll=56374

The only difference between the working and the broken runs is whether a NOTE_SORT had already been applied when FOLDER_AND_NOTE_SELECT was dispatched.

---

Suggested fix (this is running in my patched instance) - Debugging was done with AI because the bundle.js was minimized. So please take it with a grain of salt:

Mirror what newNote already does in openNote.tx, sort before selecting, so the note is at its final index on the first render:

context.dispatch({ type: 'NOTE_SORT' }); context.dispatch({ type: 'FOLDER_AND_NOTE_SELECT', folderId: folder.id, noteId: note.id, hash, });