Delete and edit loses the whole post if tap outside overlay

• Sharkey 2024.5.1
• Web Browser (desktop): Vivaldi Browser
• User agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/128.0.0.0 Safari/537.36

How to reproduce this bug?

1. On a desktop PC with a Desktop web browser, create a post.
2. Click on "delete and edit"
3. When the new overlay window displays with your post content, tap anywhere (mistakenly) and the overlay will vanish, and there is noway to recover your content.

This is the opposite effect if you had created the post from scratch, in which case, clicking on "note" would have retained your post even though you had not finished it, and allow you to continue writing.

changed the description

for whomever works on this, there are two details at work here…

first: the "draft" notes are saved under different keys in the browser's local storage depending on a few properties.

were you "delete and edit" a simple note, a quote-boost, or a reply? if it was a simple note, the the "note" button should have brought up the post; if it was a reply or quote, replying or quoting the same parent note should do the right thing too

second: it's possible that the draft is only saved when you change the text, and not when it gets pre-filled (in MkPostForm, look at the various places that mention saveDraft, and at where props.initialNote is used)

The "delete and edit" post was not a reply to another post, nor quoting anything. I was an original post (note) and then I clicked on "delete and edit", which brought up the content (text, message body), and a mistakenly tapped outside the overlay, which dismissed the overlay, but there was no means to recover the message (text) body originally displayed.

In contrast, if I had created a new post (note), and mid-typing clicked outside the overlay, I could have clicked on the new note button, and my text body would still be there. Technically, that information is so "secure" I could have navigated elsewhere within Sharkey and came back to it later (not that I recommend doing so, or consider that normal behavior).

thank you for the detail! the cause is probably the way and time that saveDraft is called, then.