Bugzilla

Before attaching a new moz-phab diff/patch, I'll describe a few other differences from my description in previous comment 100. 

- In nsImapProtocol::EndIdle() instead of setting m_imapMailFolderSinkSelected null I decided to continue to set m_imapMailFolderSink null but only do it if TB is shutting down (!waitingForResponse) or if send of "DONE" results in a successful (OK) idle response. This is more like how it has always been but will now keep the pointer around  so that the appendmsgfromfile URL failure caused by an unsuccessful ending of IDLE can still be reported and is not ignored.
- Even with this fix, when the network problems occur that cause attachment 9270480 [details] to appear, that progress dialog can remain for up to 2 minutes on linux (some shorter on windows, not sure about macosx).  This implies that the message has been 100% copied to the "Sent" folder (called Sent2 in this example) even though nothing was actually sent. 
  - The 100% can be just the final progress left over from the initial and successful SMTP send of the message. So at the end of the SMTP send, I now set the progress meter back to 0%. This is only helpful if no imap threads are available for the "append" URL so nsImapProtocol::UploadMessageFromFile() never occurs which would have also zeroed the progress meter.
  - But even with this change, if imap thread is available and the message is short it will still be successfully queued in UploadMessageFromFile() even with the network down and show 100% save to sent complete. To avoid showing 100% complete, in UploadMessageFromFile I now only allow the progress meter to go to 99%. So now the progress dialog will stay for up to 2m at 99% instead of 100%. This is still not really true but at least it doesn't imply that the save to sent was a complete success. (After a successful save to sent, 100% will still be displayed and is set in the STATE_STOP handler in sendProgress.js, but it's probably not visible since the dialog is fading out by then.)
    - To make sure the meter doesn't set a 99.9% complete transfer to 100%, I now use "trunc" instead of "round" in sendProgress.js.

Another issue is that the "indeterminate" progress state is removed with the original patch. I've received reports that some might consider this change unexpected or surprising since users are used to seeing a quick "flash" filling the progress bar when sending a message.  Currently the indeterminate progress state is the same color as percentage progress but with a slightly lighter color modulating the fully colored bar from left to right (throbbing). When sending a message this would only appear during the first "Creating mail message" message state which typically is very fast and, at least on linux, is not even visible when small messages are sent.

I personally still think showing the indeterminate state during "preparing message" state is not helpful and just showing an empty progress bar with no text percentage during this state, as it now does, is better. But some may disagree and may also prefer a more distinctive color and/or modulation pattern for the indeterminate state progress graphic.

Before attaching a new moz-phab diff/patch, I'll describe a few other differences from my description in previous comment 100. 

- In nsImapProtocol::EndIdle() instead of setting m_imapMailFolderSinkSelected null I decided to continue to set m_imapMailFolderSink null but only do it if TB is shutting down (!waitingForResponse) or if send of "DONE" results in a successful (OK) idle response. This is more like how it has always been but will now keep the pointer around  so that the appendmsgfromfile URL failure caused by an unsuccessful ending of IDLE can still be reported and is not ignored.
- Even with this fix, when the network problems occur that cause attachment 9270480 [details] to appear, that progress dialog can remain for up to 2 minutes on linux (some shorter on windows, not sure about macosx).  This implies that the message has been 100% copied to the "Sent" folder (called Sent2 in this example) even though nothing was actually sent. 
  - The 100% can be just the final progress left over from the initial and successful SMTP send of the message. So at the end of the SMTP send, I now set the progress meter back to 0%. This is only helpful if no imap threads are available for the "append" URL so nsImapProtocol::UploadMessageFromFile() never occurs which would have also zeroed the progress meter.
  - But even with this change, if imap thread is available and the message is short it will still be successfully queued in UploadMessageFromFile() even with the network down and show 100% save to sent complete. To avoid showing 100% complete, in UploadMessageFromFile I now only allow the progress meter to go to 99%. So now the progress dialog will stay for up to 2m at 99% instead of 100%. This is still not really true but at least it doesn't imply that the save to sent was a complete success. (After a successful save to sent, 100% will still be displayed and is set in the STATE_STOP handler in sendProgress.js, but it's probably not visible since the dialog is fading out by then.)
    - To make sure the meter doesn't set a 99.9% complete transfer to 100%, I now use "trunc" instead of "round" in sendProgress.js.

Another issue is that the "indeterminate" progress state is removed with the original patch. I've received reports that some might consider this change unexpected or surprising since users are used to seeing a quick "flash" filling the progress bar when sending a message.  Currently the indeterminate progress state is the same color as percentage progress but with a slightly lighter color modulating the fully colored bar from left to right (throbbing). When sending a message this would only appear during the first "Creating mail message" message state which typically is very fast and, at least on linux, is not even visible when small messages are sent.

I personally still think showing the indeterminate state during "Creating mail message" state is not helpful and just showing an empty progress bar with no text percentage during this state, as it now does, is better. But some may disagree and may also prefer a more distinctive color and/or modulation pattern for the indeterminate state progress graphic.