Open runboxdave opened 4 years ago
I keep witnessing this. Best-guessing that it is occurring in conjunction with a third party client (Thunderbird and FairMail).
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.
Reopening this as it is currently often happening in more than one account.
Happening how/where? With IMAP / runbox7 interaction on same drafts of.. something else?
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?
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.
@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?
Confirming that drafts are intermittently left after sending with Runbox 7.
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.
Thanks for the feedback -- we will increase the priority of this issue.
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.
@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.
I never use Rb6 but have the not deleted drafts despite. IMAP?
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.
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 ?
This is currently happening again, where a draft is left with a higher ID than the sent message.
As in the subject, sometimes messages which are sent continue to persist as drafts.