Edits lost after accidental back and forward navigation

[kellpossible]

The website talks about instant saves https://usememos.com/features/instant-save but this only applies to new notes, not edits to existing ones?

[jmrplens]

Your reading is right, and it is deliberate rather than a bug. I checked it on a throwaway 0.30.0 instance with a browser driving it, doing the same thing twice.

Typing into the composer without saving, navigating away and coming back: the text is still there. Opening an existing memo with Edit, changing the text without saving, navigating away and coming back: the change is gone and the original content is back.

The mechanism is useAutoSave in web/src/components/MemoEditor/hooks/useAutoSave.ts, which persists the editor content and already-uploaded attachments to localStorage. It is mounted in MemoEditor/index.tsx like this:

const isDraftCacheEnabled = !memo;
const { discardDraft } = useAutoSave(currentUser?.name ?? "", cacheKey, isInitialized && isDraftCacheEnabled);

The third argument is enabled, and isDraftCacheEnabled is simply !memo. The same editor component is used for both jobs, and the only thing separating them is whether a memo was passed in. Create mode has no memo, so the draft cache runs. Edit mode has one, so it does not. A comment a few lines down says the same thing about timestamps: "Only applies in create mode; edit mode owns its own timestamps."

So the instant save page is accurate about what it covers, and the gap you hit is that it covers the composer only.

If you want to raise it, the useful shape is probably not "autosave edits too" but "give edit mode its own draft key", because the caching layer already namespaces keys. web/src/lib/resource-names.ts notes it namespaces the editor draft cache key by Space "so drafts never bleed across contexts", so keying a draft by memo name looks like it would fit the existing machinery rather than needing new plumbing. Until then, the safe habit with an open edit is to save before navigating, since nothing recovers it afterwards.

[jmrplens]

Correcting myself: I suggested above that #5740 was closed only for staleness and might be worth reviving. That is wrong, and the real history is more specific.

9ca7122 on 10 April added exactly the behaviour you are asking about. useMemoInit loaded the cached draft and preferred it over the saved memo content when reopening an editor, with a comment naming the case: "Prefer cached draft over the saved memo content when the user had unsaved changes (e.g. tab was suspended mid-edit)".

Ten days later b5863d7, "fix(web): preserve task checkbox state (#5867)", removed that block and introduced the line I quoted, const isDraftCacheEnabled = !memo. So edit-mode drafts were not overlooked, they were given up on purpose: with the cache active in edit mode, ticking a checkbox on a saved memo could bring back a stale draft over the real content.

#5740 was open across that window, which is the likely reason it went nowhere, and reviving it as written would put back what #5867 removed.

So the gate is deliberate after all, and the request worth making is narrower than "cache edit drafts too". It needs a draft key that can tell an unsaved human edit apart from a content change the app itself made, which is the part the earlier attempt did not have. Apologies for the detour.