search

runbox / runbox7

Runbox 7 web app
Other
127 stars 24 forks source link

Drafts are sometimes/often not deleted when the message is sent #644

Open runboxdave opened 4 years ago

runboxdave commented 4 years ago

As in the subject, sometimes messages which are sent continue to persist as drafts.

kotecky commented 3 years ago

I keep witnessing this. Best-guessing that it is occurring in conjunction with a third party client (Thunderbird and FairMail).

castaway commented 2 years ago

Tested: create draft in runbox7, save as draft, then send using IMAP client - draft is still present in runbox7 after sending. Its gone from Drafts in the IMAP client.

gtandersen commented 1 year ago

Reopening this as it is currently often happening in more than one account.

castaway commented 1 year ago

Happening how/where? With IMAP / runbox7 interaction on same drafts of.. something else?

gtandersen commented 1 year ago

I believe it occurs (inconsistently) when sending a message from Runbox 7 without interacting with any other interfaces.

@runboxdave Do we have any more details from users?

kotecky commented 1 year ago

I have the issue but only go to the Drafts folder in the web app, seldom elsewhere. The combination of devices I use is Thunderbird on Win10/IMAP, FairMail on Android/IMAP, and the RB7 web app on Firefox on Win10 and Android.

At the very moment there are few drafts of items sent today, visible in FairMail and in RB7. I did nit use Thunderbird today yet.

castaway commented 1 year ago

@kotecky thanks! Can I get a bit more detail? Do you create & send emails with all those clients? The drafts that are hanging around after you sent them, do you know which clients they were a) started with b) sent with?

gtandersen commented 1 year ago

Confirming that drafts are intermittently left after sending with Runbox 7.

MoritzLost commented 1 year ago

I'm also seeing this issue, it's very frequent. More often than not, a draft will remain in the drafts folder after sending the email.

gtandersen commented 1 year ago

Thanks for the feedback -- we will increase the priority of this issue.

gtandersen commented 1 year ago

This may seem to involve Runbox 6 as it can thus far only be reproduced in a test account while Runbox 6 is also open in the same browser.

MoritzLost commented 1 year ago

@gtandersen In my case, this was definitely not the case – I have never used Runbox 6, and I have seen this issue with only a single Runbox 7 tab open.

kotecky commented 1 year ago

I never use Rb6 but have the not deleted drafts despite. IMAP?

antoniskalou commented 1 year ago

I managed to replicate this on my own account and using the debugger it seems to be an issue with the autosave feature. The mail is sent and then autosave runs, re-sending the draft to the backend.

Unfortunately the issue magically disappeared after the weekend, so I'm not able to investigate further.

I've added a possible fix by forcing the autosave feature to only trigger when value changes in the email occur. We'll have to see if this fixes the issue as I can't replicate anymore.

castaway commented 1 year ago

Retested this and managed to capture some more behaviour:

If we're in HTML drafting mode, and we send the draft, we close the draft compose component, which destroys itself, calling tinymce.remove(this.editor); in the process. This remove triggers (why!?) the editor onChange event, which updates the value of the fromGroup control "msg_body", which triggers a save.

Suggestion: Call editor.off('change') (removes the onchange event), before the .remove ?

gtandersen commented 3 months ago

This is currently happening again, where a draft is left with a higher ID than the sent message.