Closed Bug 1072628 Opened 10 years ago Closed 5 years ago

Cancelling (canceled) send -- sends message anyway AND eliminates copy in sent folder

Categories

(Thunderbird :: Untriaged, defect)

31 Branch
x86_64
Windows 8
defect
Not set
normal

Tracking

(Not tracked)

RESOLVED DUPLICATE of bug 882617

People

(Reporter: educmale, Unassigned)

References

(Depends on 1 open bug)

Details

(Whiteboard: [dupeme?])

User Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:32.0) Gecko/20100101 Firefox/32.0 Build ID: 20140917194002 Steps to reproduce: Composed a long message, hit send. While it was "uploading", i hit the cancel button. Using TBird 31.1.1 Actual results: The send was aborted (i thought...), and then another dialog box was displayed I hit cancel within that 2nd dialog box (I'm not sure what it said, but it was -not- the dialog saying that the mail couldn't be sent and to check your server....) The mail, presumably unsent, disappeared. It was not available to continue editing (the compose window was gone); it was not in the mail account's draft or sent folders, nor was it in the local/outbox. I contacted the recipient, due to my perplexed soul; he got the email. It -was- sent! (I requested a copy back from the recipient) Expected results: Tbird should have cancelled send, left me an copy to edit. And/Or: if something is sent, save it in the sent folder. In the specific sense of this bug, there should NEVER be an email sent which does NOT show up on the sent folder. Something about timing is messy, when the context of using the 'cancel' button runs up against the sending code and the store-a-copy in the sent folder code. Wish I could be more helpful about the second dialog and cancel I encountered. It either was, or i figured it was at the time, a) cancelling the send or b) cancelling an "TBird is going to abort edit". Whatever happened, that mail went out! Note: Sometimes, in this and prior versions, I have hit the cancel button, thinking, "eh...might want to edit..." and the message gets sent anyway, and -does- show up in the sent folder. (usually when the progress bar is close to the end...) In that case, there needs to be a formal way for the button to be clicked and ignored, and the user is specifically told: "Eh...we're ignoring that cancel because you clicked it too late", or getting rid of the "cancel" button / cancel-ability at some earlier point in the code's process(es), so that if the button -is- still clickable, it -will- still cancel the send. (I can imagine something tortuous about mailServer protocols which allow this sub-bug to happen)
Addendum: Additional suggestion for the sub-bug, noted above in the context of this error detection: if the button -is- clicked, and the server connection has been made and mailing completed: The user should be told: "Eh ... that cancel request was too late. Server connection completed. Mail sent (and stored in your sent folder [[if saved....]] ) Should I create this as a separate bug? In my head the bug and this sub bug are related. As it is, now, there is no notice that the cancel was ignored, other than hunting around for the message to check. (Up till now, it always was there; that I cancelled and it was sent anyway -and- there was no record, was the cause for the bug report). Note: Though there was no message in the sent folder, the line for the message to which I replied -did- have a replied arrow. This arrow disappeared after I repaired that specific inbox folder. 'Repairs' on the other mentioned folders (Sent, draft and outbox) did -not- change anything, and the sent message never appeared.
Something about bug 120278 seems similar, but not quite Seems like there are two error cases -- where the send-message fails, and the expected result is not leaving the user with a draft message or other opportunity to send. The second case, this bug, where the message -is- sent, and there is no history to evidence it.
See Also: → 120278, 776042
Whiteboard: [dupeme?]

Very similar (albeit slightly different in that compose window was gone) to bug 882617. Probably timing.

See Also: → 882617

Thanks. Let's dup to bug 882617 and if that turns out to not resolve John's issue we can reopen

Status: UNCONFIRMED → RESOLVED
Closed: 5 years ago
Depends on: 882617
Resolution: --- → DUPLICATE
You need to log in before you can comment on or make changes to this bug.