WADA:World Anti-bad-Duping Agency Reporter
	Description • 14 years ago

Old draft mail saved in IMAP Drafts folder is not deleted, if "save by auto-save" and "save by Save As Drat" happens at same time.

This is a result of intentional tests for many reports of "draft is not deleted" which are perhaps contention between "draft save by auto-save, or  delete of old draft by auto-save" and "delete of old draft after mail send" which can happen when;
(a) Mail send occurs during auto-save. 
(b) Auto-save is invoke even after mail send is requested.
This bug is to provide "Steps to reproduce problem" in order that developers can see phenomenon of this kind of "draft is not deleted" easily.
Because this bug is probably phenomenon of "contention of Draft folder between auto-save and Save As Draft", this bug is perhaps different from problem due to above (a) an (b). 

[Buil Identifier]
> Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.14) Gecko/20110221 Thunderbird/3.1.8

[Steps to re-produce problem]
(1) Setups.
    - Yahoo! Mail IMAP account (\Deleted flag is kept normally).
      If Gmail IMAP, auto-expunging=off of Gmail IMAP is recommended.
    - offline-use=on or off of Drafts folder was irrelevant.
    - To observe phenomenon easily, use "Just mark it as delete" model.
    - Enable new mail check to make it worse.
    - Enable IDLE command use to kake it worse.
    - Use "All Folders" view at folder pane to avoid confusion.
      Don't use "Unified Folders" view to avoid confusion.
    - Enable next option for ease of observation.
      [ X ] Show  confirmation dialog when messages are saved
    - Interval of auto-save : 1 minutes
(2) Open Drafts folder
(3) Compose a mail of big attachment(s). (4MB mail is used for test) 
    Change Subject: to subject-1, Save As Draft.
(4) Change ubject: to subject-2, wait for start of auto-save.
    When auto-save starts(progress bar is shown),
    immediately change Subject: to subject-3 and execute Save As Draft.
(5) After a while, dialog of "save to Draft fail, Retry? OK/Cancel" appears.
    Reply "OK"
    => draft save is retried(but no feed back like progress bar)
(6) After a while, new mails in Drafts is detected.
(7) Before next auto-save, go to step (4).
(8) Repeat step (4) to step (7) multiple times.
    => Several "not-deleted draft mails" are seen in Drafts folder.

	WADA:World Anti-bad-Duping Agency Reporter
	Comment 1 • 14 years ago

For any auto-save related problem, I think next is a good and effective solution.

If auto-save is already started, don't invoke "Save As Draft", "Mail send".
If "Mail send" is already requested, don't invoke auto-save.

	Wayne Mery (:wsmwk)
	Comment 2 • 14 years ago

nice wada!

I bet this will solve many problems. Note: many users mention large message or many attachments (which increase autosave and send time) when they report this problem.

Additionally, problem may be more severe if multiple draft messages are open.
(I may have mentioned this in another bug.)

	WADA:World Anti-bad-Duping Agency Reporter
	Comment 3 • 14 years ago

(In reply to comment #2)
> Additionally, problem may be more severe if multiple draft messages are open.

I think so too.
Multiple "draft save" processes to same Drafts folder, or multiple accesses to an IMAP Drafts folder, should be serialized, in order to avoid Drafts folder contention and/or interfering each other. I'll perhaps lower probability of interlocking.

For auto-save relevant issues, change like next may be a solution.
  Auto-save always saves in local mail folder.
Because main purpose of auto-save is protection from draft data loss due to crash, there is no need to save huge draft mail data to IMAP folder. IIRC, this kind of enhancement is already requested.

	WADA:World Anti-bad-Duping Agency Reporter
	Comment 4 • 14 years ago

FYI.
Following is copy of bug 476074 comment #20 by David.
> deletes are done in two steps - we do the initial delete as an offline operations, 
> and delete the headers from the UI. Then, half a second later, we
> playback the offline operation, which sends the command to the server.
> It sounds like the second phase is blocking the UI, for some reason.
This may be relevant to "freeze after mail send" seen in other bugs and "UI freeze" which could be observed during test for this bug.

	WADA:World Anti-bad-Duping Agency Reporter
	Comment 5 • 10 years ago

Auto-Save is scheduled by following code.
> http://mxr.mozilla.org/comm-central/source/mail/components/compose/content/MsgComposeCommands.js#4504
> function AutoSave()
> {
>   if (gMsgCompose.editor && (gContentChanged || gMsgCompose.bodyModified) &&
>       !gSendOperationInProgress && !gSaveOperationInProgress)
>   {
>     GenericSendMessage(nsIMsgCompDeliverMode.AutoSaveAsDraft);
>     gAutoSaveKickedIn = true;
>   }
>   gAutoSaveTimeout = setTimeout(AutoSave, gAutoSaveInterval);
> }

gSendOperationInProgress and gSaveOperationInProgress is used at :
http://mxr.mozilla.org/comm-central/search?string=gSaveOperationInProgress
http://mxr.mozilla.org/comm-central/search?string=gSendOperationInProgress

gSendOperationInProgress=true or gSaveOperationInProgress=true is set here only(in GenericSendMessage).
> http://mxr.mozilla.org/comm-central/source/mail/components/compose/content/MsgComposeCommands.js#2712
>     var progress = Components.classes["@mozilla.org/messenger/progress;1"]
>                              .createInstance(Components.interfaces.nsIMsgProgress);
>     if (progress)
>     {
>       progress.registerListener(progressListener);
>       if (msgType == nsIMsgCompDeliverMode.Save ||
>           msgType == nsIMsgCompDeliverMode.SaveAsDraft ||
>           msgType == nsIMsgCompDeliverMode.AutoSaveAsDraft ||
>           msgType == nsIMsgCompDeliverMode.SaveAsTemplate)
>         gSaveOperationInProgress = true;
>       else
>         gSendOperationInProgress = true;
>     }

After GenericSendMessage is started, g????OperationInProgress=true is set when progress meter for Send, Manual-Save, Auto-Save, etc. is initiated...
How can "Auto-Save after Send is requested and Send operation is started" be avoided by this logic/mechanism?
Time lag between "GenericSendMessage call for Send or Save" and "gSendOperationInProgress=true or gSaveOperationInProgress=true by GenericSendMessage logic" surely exists.
So, auto-Save and Send surely can be executed at same time.

gSendOperationInProgress and gSaveOperationInProgress is designed for Send request and Save request via UI which locks UI.
At least locking like next is needed.
    function AutoSave() { 
        if (     !gAutoSaveProhibited &&
                 gMsgCompose.editor && (gContentChanged || gMsgCompose.bodyModified) &&
                 !gSendOperationInProgress && !gSaveOperationInProgress )
                 gAutoSaveProhibited=true, and Call GenericSendMessage() for Auto-Save;
    function GenericSendMessage() .
        gAutoSaveProhibited=true, as first statement of  GenericSendMessage.
    At appropriate place, gAutoSaveProhibited=false after normal end Save, 
    or gAutoSaveProhibited=false when Cancel etc. occurred during Send, Save etc.

IIRC, "stop invoking Auto-Save when Send is started" was tried by "gMsgCompose.bodyModified=false or gContentChanged=false upon send request", but it maybe was not "set true to both", and, I think "Time Lag" exists too.
I don't know about "Send is executed while Auto-Save is in progress" case. 
    draftID=#1,
    Auto-Save is invoked,         While Auto-Save is running, Send is requested.
    and saves as #2, 
    delete draftID=#1, 
              <= Send completes at here -> try to delete draftID=1, but not found. save to Sent, close window -> #2 is not deleted.. 
    set draftID=#2
              <= Send comletes at here -> delete draftID=2. save to Sent, close window ->#2 is normally deleted.
Send usually takes longer than Save, so #2 is usually deleted, but if IMAP Drafts, Save to Drafts may be slower than SMTP send.

	WADA:World Anti-bad-Duping Agency Reporter
	Comment 6 • 10 years ago

When Send/Save(manual) is normally executed, gAutoSaveProhibited can be reset at here.
If Send, reset shouldn't be executed at here. It should be reset upon initiation of Auto-Save by next mail composition start.
> http://mxr.mozilla.org/comm-central/source/mail/components/compose/content/MsgComposeCommands.js#420
> 420       if (aStateFlags & Components.interfaces.nsIWebProgressListener.STATE_STOP)
> 421       {
> 422         gSendOperationInProgress = false;
> 423         gSaveOperationInProgress = false;
>        +     If Send-Type==Not-Send(==Save/AutoSave) gAutoSaveProhibited=false;
When Send/Save(manual) is canceled, where is appropriate place to reset gAutoSaveProhibited?

	WADA:World Anti-bad-Duping Agency Reporter
	Comment 7 • 10 years ago

> When Send/Save(manual) is canceled, where is appropriate place to reset gAutoSaveProhibited?

All send/save request looks processed by GenericSendMessage().
So, when GenericSendMessage() returns without setting gSaveOperationInProgress = true or gSendOperationInProgress = true at any place in GenericSendMessage(), gAutoSaveProhibited=false should be set...

	WADA:World Anti-bad-Duping Agency Reporter
	Comment 8 • 10 years ago

If so, wrapper of GenericSendMessage() may be needed.
   function GenericSendMessage(...) {
      gAutoSaveProhibited=true;
      GenericSendMessage_Actual(...); // Copy of current GenericSendMessage()
      if( gSaveOperationInProgress != true && gSendOperationInProgress !=true ) gAutoSaveProhibited=false;
   }