786868 - Imap: Missing button to [Save...] sent message when disconnected causes dataloss - improve UX of "There was an error saving the message to Sent. Retry?" dialogue

Status: RESOLVED DUPLICATE of bug 28211

(Thunderbird :: Mail Window Front End, defect)

Description

[[e-mail]]

User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:14.0) Gecko/20100101 Firefox/14.0.1
Build ID: 20120713134347

Steps to reproduce:

When there's some network problem reaching the IMAP server, occasionally mail messages that are sent cannot be copied to the sent mail folder.  This is often a transient error.  Sending a message results in the dreaded "There was an error saving the message to Sent. Retry?" dialog.


Actual results:

I keep clicking retry or give up on thunderbird until the network transient clears - pressing "cancel" results in the message being lost to the aether.  


Expected results:

Add two variables
A user-definable "silent_retry_time=3600" (XX minutes)
A user-definable "retry_period=36000" (YY Minutes)

Phase 1:
After retrying for XX minutes a status window message (non-modal) should appear that reads something like "For information only: Z messages have not been copied to your sent mail.  I will keep retrying for YY minutes.  You do not need to do anything, this is for your information only."

Phase 2 
After YY minutes a non-modal dialog should be displayed that says "I have not been able to copy Z messages to your sent mail box for YY minutes.  This may be a server configuration error.  [keep trying silently] [edit message] [stop trying]"

Comment 1

[[e-mail]]

This is still a bug/missing enhancement.  

A possible workflow improvement in the event that one's state is "online" but the remote IMAP server is transiently (or becomes extended-ly) unavailable would be to silently revert to offline mode - perhaps throwing a message into the soon to be released "message pane" which will replace ALL modal dialog boxes so TB users never, ever have to suffer the indignity of a modal dialog box again.  

Auto-offline would ease offline/online transitions in rushed circumstances (running for a plane, for example) and mitigate the annoyance of **** connections where remote server availability comes and goes.

My preference would be to retain "true offline" (e.g. intentional offline regardless of network state) and convert "online" to "opportunistic online" which would silently transition to offline behavior on connection failure, but silently background check for server availability and restore online operations when remote servers reappear.

As many users configure TB to work against multiple remote servers, this should be implement per remote server - that is if mail.alice.com is accessible, it stays "online" even if mail.bob.com drops and automatically switches to "offline" with local storage of drafts and pending outgoing messages.  Note further that SMTP for all accounts may be with smtp.alice.com and remain available while the "sent" mail folder on mail.bob.com is missing - TB should Do The Right Thing and silently queue the "copy to sent" operation until bob.com reappears.

Comment 2

[Thomas D. (:thomas8)]

This sounds very much like going into the right direction, including the UX details as laid out in comment 0 (comment 1 looks more like a new bug with bigger scope).
-> confirming

Don't expect anything to happen here though unless you do it yourself...

Comment 3

[Thomas D. (:thomas8)]

Search for related / similar bugs:

:thun,mail su:error su:saving
https://bugzilla.mozilla.org/buglist.cgi?quicksearch=%3Athun%2Cmail%20su%3Aerror%20su%3Asaving;list_id=5468608

Comment 4

[[:jberkus] Josh Berkus]

This is related to bug 817392

Comment 6

[Thomas D. (:thomas8)]

As hinted here in comment 0 ("message being lost to the aether.") and described with more detail in duplicate bug 1126069, this is a dataloss bug because in case of network failure there's no way to save the sent message. -> critical

Comment 7

[Christopher]

Note that my Bug 1126069 describes more a problem with the UX design of the "retry dialog" (critical, but very simple to solve) and not something related with the IMAP protocol itself.

Comment 8

[t_jeske]

And still a problem in March 2017 with current version (and alle versions dating back at least 12 months).