1089452 - attachments appears not to be deleted at message window, and \Deleted flag is not stored to original mail, when detaching/deleting attachments from IMAP mail opened from "Search Messages" or a "Saved Search Folder"

Status: NEW

(MailNews Core :: Networking: IMAP, defect)

Description

[hippiefreak]

User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; Trident/7.0; SLCC2; .NET CLR 2.0.50727; .NET CLR 3.5.30729; .NET CLR 3.0.30729; Media Center PC 6.0; .NET4.0C; .NET4.0E; BRI/2; rv:11.0) like Gecko

Steps to reproduce:

I perform Shift-Control-F to open the Search Box. I search and find emails ok. I double-click on any email in the Search results, it opens just fine. If the email has attachments, I elect to remove the attachments by first right-clicking on the word "attachments" in the bottom status bar of the opened email. I select "Delete All" from the little menu that results. A pop-up appears, listing the attachments and advises me the deletion is permanent; do I wish to continue? I click Yes.


Actual results:

The attachments do not delete.


Expected results:

The attachments should have deleted. May I point out that this problem only occurs when trying to delete attachments from emails listed in the Search Results Box. If I instead merely click on a folder in my left pane then select any email from the right pane, I can always successfully delete the attachments using the same steps outlined above. Only with emails opened from the Search Box does this problem always occur.

Comment 1

[WADA:World Anti-bad-Duping Agency]

IMAP? POP3?

I couldn't see "Unable to Delete attachment" on mail in local mail folder in Tb 31.3.0 on Win.
I could see only following by "Delete attachment of mail in local mail folder".
1. 2 mails exists in FolderX, Search FolderX, Open mail #1 -> opened at new Tab
2. Delete attchment -> mail #2 is shown, or Tab is closed if only one mainlin folder
3. mail #1 disappears at Threaad Pane of FolderX
4. Click other folder, click FolderX again -> mail #1 appears with attachment deleted.
    Rebuild-Index doesn't look to be invoked because Done is not shown at status bar.
    Deleted flag is normally set in X-Mozilla-Status: of old versio of mail.
    Offset of new version is end of FolderX file(i.e. new version was normally appended.)

Gmail IMAP?
If so, "Unable to Delete attachment" may occur,. Because Gmail holds only single copy of a mail, if Gmail considers "newly appended mail with attachment Detached /Deleted" == original mail, Gmail ignores newly appended mail data.

If POP3 or Local Folders, did you check msgStore file content? (if FolderX, file named FolderX, not FolderX.msf)
Did you try "Repir Folder" when you saw your problem?

Comment 2

[hippiefreak]

This is OP. Are you talking to me? 
My email account is IMAP. It is not Gmail IMAP. I have Tb 31.3.0 on Win7.
I do not know/understand msgStore or "Repir Folder" ideas. I am not a sophisticated user.
However, if you can recap still-relevant questions based on this new information, and add new questions, I can ask someone to help me answer them.
Thank you.

Comment 3

[WADA:World Anti-bad-Duping Agency]

(In reply to hippiefreak from comment #2)
> Are you talking to me?

How can question in comment #1 be question to other than bug opener?

> My email account is IMAP.

Gotcha. This is reason why you could see "many duped mails" but we could see "phantom mail" only in bug 1106225.

> I dot know/understand msgStore

msgStore is file used to save mail data of a local mail folder. If folder named Inbox, file named Inbox instead of Inbox.msf.
If IMAP, mail relevnt to Mbox at server is held in msgDababase file(.msf), and if auto-sync is enabled and Offline-use=On(Folder Properties/Synchroniztion), entire mail data is held in Offline-Store file. If Mboxnamed Inbox, file named Inbox instead of Inbox.msf.

> I do not know/understand "Repir Folder"

Folder Properties/General.

You can't access Google in your country? If you can access Google, you can do Google Search...

If IMAP, and if your problem is persistently reproducible, get NSPR log and check log file content by yourself using text editor..
See NSPR log I attached to bug 1106225. See bug 402793 comment #28 for getting NSPR log. timestamp,MsgCopyService:5,imap:5 may be helpful.

Comment 4

[hippiefreak]

> How can question in comment #1 be question to other than bug opener?

You would have to be completely inexperienced with this ticket system, and have never seen it before, to understand the answer to that question. That makes you over-qualified! ;)

> You can't access Google in your country? If you can access Google, you can do Google Search...

Oh boy, you must be assuming I know anything. I'm gonna find the buddy who told me to come to this site to open a tkt and smack him upside the head for setting me up. I am not a peer. Feel free to cancel/close this ticket. Hopefully someone experienced with have this problem in the future and will open a tkt and can help. Thank you.

Comment 5

[Magnus Melin [:mkmelin]]

hippiefreak: thx for the report, I can reproduce. It appears though that the attachments ARE deleted, but the original is not deleted, so you're just looking at the original mail...

(Technically deletion happens by creating a new copy without the attachments, and then deleting the original. )

WADA: yes, bugzilla is not for end user support, but we do need bug reports from non-expert users

Comment 6

[WADA:World Anti-bad-Duping Agency]

(In reply to Magnus Melin from comment #5)
> I can reproduce. It appears though that the attachments ARE deleted, but the original is not deleted,
> so you're just looking at the original mail...

I also confirmed it with non Gmail-IMAP(Yahoo! IMAP) with IMAP delete model of "Remove immediately".
I checked with local mail folder first, with Gmail IMAP second, so I couldn't see phenomenon :-)
1. if IMAP mail is opened from SearchDialog, old version of Detach/Delete is not deleted(store flag \Deleted is not requested).
2. at opened message window/tab, non-deleted original is still shown, because "delete of old version" doesn't occur.
3. at SearchDialog, non-deleted original mail is still shown, because "delete of old version" doesn't occur.
4. because of SearchDialog, newly added mail(with attachment Detached/Deleted) is not automatically shown.
5. at Search Target folder, both non-deleted old version aand newly added version is shown.
    old version is shon even after "Repair Folder", because "store flag \Deleted" is not requested.

"What was actually not deleted" was "originaal mail" instead of "attachment data".

Comment 7

[WADA:World Anti-bad-Duping Agency]

I tried test with non Gmail-IMAP(Yahoo! IMAP), with IMAP delete model = "Remove immediately" and with IMAP delete model = "Just mark it as deleted", and with "Open in new message window" or "Open existing new message window", with Offline-Use=Off folder only, several times.
But I couldn(t see phenomenon of "original mail is not deleted(store flag(\Deleted) is not issued) after Attachment Delete" again.
I could observe is following only.
1. If "Remove immediately", after Delete/Drtach at opened message window from SerchDialog,
    one off next always occured.
    1-a :  Next mail at SeaarchDilog is shown at "opened message window from Serch dialog"("open in new message window").
    1-b :  "opened message window from Serch dialog" is closed. (lst message is deleted, or "open in existing message window").
2. If "Just mark it as deleted", after Delete/Drtach at opened message window from SerchDialog,
    Deleted/Drtached atatchment is still shown as not-Deleted/not-Detached, because originl is deleted(\Deleted is stored)
    but msgDBHDR is accessible even after mail is deleted, because of "Just mark it as deleted" model.
    However, in this case, "deleted but not removed originl mail" is always shown as "delete mail" with trash caan icon and
    strike-thru line  at SearchDilog,  as far as Search Target folder is single folder(check subfolders is Unchecked).

i.e. I could see phenomenon of "attachments appears not to be deleted when deleting attachments from mail opened from Search Messages" only with "Just mark it as deleted" and only at "opened message window". "Original is not deleted" couldn't be observed at SearchDialog. Original mail was always shown as "deleted mail" at SearchDialog after Delete/detach of attachment.
If "Remove immediately", next maail is shown at "opened message window from Search" after Delete/Detach, or "opened message window from Seaarch"  is closed after Delete/Detach, so I couldn't see phenomenon of "attachments appears not to be deleted when deleting attachments from mail opened from Search Messages".

Magnus Melin, problem with "Move to trash" model?
If so, it may be timing dependent issue.
   If  "Move to trash", (i) "append new version" + (ii) "copy ooriginal to Trash" + (iii) "store flag \Deleted to original" is needed.
   So, state of "delete of original mail" may not be reflected to SearchDialog/"opened message window/tab" at aproprite timing.
Following phenomenon is observed.
-  When Tag state is changed at "opened message window by SerchDialog",
    it's immedately reflected to Real folder, Virtul folder(Search Folder).
    But when Tag state is changed at Real folder, Virtul folder(Search Folder),
    Tag state is not reflected to  "opened message window by SerchDialog".
    Some aactions, such as state change at message window, is neeeded to know Tag stte chanfe. 
 i.e. Some ebents are "one way"  between "Real folder/Virtual folder/Search Dilog" and "opened message window".

Comment 8

[WADA:World Anti-bad-Duping Agency]

I could observe following reeatedly with non Gmail-IMAP(Yahoo! IMAP), with IMAP delete model = "Move to trash" , and with "Open in new message window", with Offline-Use=Off folder only, several times, using Virtual Folder(Search Folder), at last.
1. Open a message window from Search Folder
2. At message window, Delete attachment =>Nothing is changed at message window. Attachment box is unchanged.
3. At Search folder : "New version with atachment deleted" is added. Original version still remains. Original is not deleted.
4. At Trash : Nothing is added.
5. At Real Folder : "New version with atachment deleted" is added. Original version still remains. Original is not deleted.
However, after some "IMAP delete model" change to view or hide "mail flagged \Deleted" mails, and after some restarts of Tb, I couldn't phenomenon like above. Even when  IMAP delete model = "Move to trash", detached/deleted mail was deleted(\Deleted is stored as expected).
Needless to say, if IMAP delete model = "Just mark it as deleted", "mail flgged as \Delete" can be viewed/edited(Edit As New) any time. "mail flgged as \Delete" is merely an active mail which has \Deleted flag in "Just mark it as deleted" model.

Problem like next?
1. Detach/Delete is "Edit As New of original" internally. So original is not deleted after "Edit of the mail".
     Note: Even if draftID=original mail && deleteDraft=true is set, it's ignored unless draftID is mail in Drafts folder.
2. So Tb tries to delete original mail(like Shift+Delete)
3. gDBView of messae window opend from Search Folder/SearchDialog inherits "IMAP delete model when window is opened".
    If "IMAP delete model when message window is opened" != ."Move to trash", 
        "delete original" is "Store flag \Deleted" only, and msgDBHdr is immeditely removed, or kept.
    If "IMAP delete model when message window is opened" == ."Move to trash", 
       "delete original" is "triy to move to Trash" + "remove sgDBHdr after successful move to Trash"..
       because original is still viewed at message window, "move to Trash" fails or is skipped.
4. At Real Folder, IMAP delete model change is reflected immediaately upon the Reaal Folder is re-opened.
    If "current MAP delete model" != ."Just mark it as deleted", msgDBHDr of mail flagged \Deleted is removed.
    If "current MAP delete model" == ."Just mark it as deleted", msgDBHDr of mail flagged \Deleted is fetched and kept.removed. 
5. New msgDBHdr by step 4, or removed msgDBHdr by step 4, is propagted to Swearch Folder/SeaarchDialog.
6. If magDBHdr of UID=nn which is used at "opened message window by Search"  is removed by step 5,
     message window is closed if lst mail, and if non-last mail, next message at Search Folder/SerchDialog is shown.
    If magDBHdr of UID=nn which is used at "opened message window by Search"  is not removed by step 5,
    message window is kept open, and UID=nn is still shown at message window.

Comment 9

[WADA:World Anti-bad-Duping Agency]

Anyway, unless I change IMAP delete model while Tb is running, I could observe with non Gmail IMAP(Yahoo! IMAP) is;
(a) If IMAP delete model = "Move to trash" or "Remove immeditely",
      when Detach/Attach is executed at message window opened from SearchDialog/Search Folder,
      (a-1) \Deleted flag is normally stored to originl mail, and it disappears from SearchDialog, Search Folder, Real Folder.
      (a-2) New version of mail normally appears at Search Folder, Real Folder. I'm not sure about SearchDialog case, 
      (a-3) If opened message is last message in SearchDialog/Search Folder, message window is closed.
                If opened message is not last message in SearchDialog/Search Folder,
                next message at SearchDialog/Search Folder" is shown in the opened window from SearchDialog/Search Folder.
(b) If IMAP delete model = "Just mark it as deleted",
      when Detach/Attach is executed at message window opened from SearchDialog/Search Folder,
      (b-1) \Deleted flag is normally stored to original mail,
                but it still remain at SearchDialog, Search Folder, Real Folder, because of "Just mark it as deleted" model.
      (b-2) New version of mail normally appears at Search Folder, Real Folder. I'm not sure about SearchDialog case, 
      (b-3) Because of "Just mark it as deleted" model, "mail \Deleted is stored" is merely an active mail of "flagged as \Deleted",
                it still shown in the opened window from SearchDialog/Search Folder.

Confusing phenomenon for user is (b-3).
Tb is better to show "new version after Detach/Delete" at opened message window.

By the way, after repeated tests of "Delete  attachment at opened message window from Search Folder" with repeated IMAP delete model change  while Tb is running, I saw a crash.
Problem around "IMAP delete model detection/determination in Virtual Folder" surely exists.
   If multiple search target folders, "show mail of \Deleted flag, or not" is determined by:
      "IMAP delete model" of account which has smallest messageKey(Order Received column value) in search result.
   So, shown result, shown state(with trash can icon or not if flag of \Deleted, or without it) is pretty inconsistent. 
It looks that "when used IMAP delete model is determined" is relevant if "opened message window" is related to phenomenon.
I believe these are essentially irrerevant to this bug. These are relevant to funny phenmena which I saw duplication test.

Comment 10

[WADA:World Anti-bad-Duping Agency]

(In reply to Magnus Melin from comment #5)
> I can reproduce. 

Magnus , How did you reproduce what phenomenon with what conditions?
Is it same as original problem by bug opener in comment #0?

Comment 11

[WADA:World Anti-bad-Duping Agency]

(In adition to comment #9)
> Confusing phenomenon for user is (b-3).
> Tb is better to show "new version after Detach/Delete" at opened message window.

If message window is opened from Real Folder, following occurs with IMAP delete model = Just mark it as deleted, with "open in new window".
1. Detele attachment at message window.
2. At Real Folder, old version is shown with trash can icon, strike-thru line, and new version appears.
3. At message window, new version(attachment is deleted) is shown.
This is difference between "message window opened from Real Folder" and "message window opened from Search Folder/SearchDialog".

Some causes of difference are : 
- When Just mark it as deleted model, msgDB event of HdrDeleted doesn't occur at Real Folder
   when \Deleted flag is stored to original mail.
   If Shift+Deleted is executed, msgFolder event of MessageDeleted occurs but msgDB event of HdrDeleted doesn't occur.
- No differnce is seen in code when message window is opened from Search and when opened from Real Folder.
   Difference is gDBView etc. (inherited from opener of message window),
   and assocaited msgFolder to the view is different: one is  Real folder, another is Virtual folder.,
   Associated folder to processed msgDBHdr is Real Folder where the message is held. This is same in both case.

I still see phenomeno of "\Deleted flag is not stored by Delete attachment at message window opened from Search Folder" sometimes in my test because I change IMAP delete model sometimes, but it can not be produced consistently. It always occurrs accidentally.

Note:
If IMAP delete model = "Move to trash" or "Remove immediately", msgDBHdr of original is removed by Delete/Detach.
So, following occurs in both "message window opened from Real Folder" and "message window opened from Search Folder/SearchDialog" :
(i)  If open in existing message window :  message window is closed.
(ii) If open in new message window :  "next message at Real Folder/Search Folder/SearchDialog" is shown if it exists.
                                                              if no next message, message window is closed.
Tb's behviour is consistent in message window opened by Real Folder/Search Folder/SeaarchDialog. Therefore, user's confusion won't be produced in this case.

Comment 12

[Magnus Melin [:mkmelin]]

(In reply to WADA from comment #10)
> (In reply to Magnus Melin from comment #5)
> > I can reproduce. 
> 
> Magnus , How did you reproduce what phenomenon with what conditions?
> Is it same as original problem by bug opener in comment #0?

AFIAK yes. I searched an IMAP (mark-as-deleted preffed) account for messages, opened and tried to delete attachments. I then noticed the message was duplicated in the folder but only the original message had a large size.

Comment 13

[WADA:World Anti-bad-Duping Agency]

(In reply to Magnus Melin from comment #12)
> AFIAK yes. I searched an IMAP (mark-as-deleted preffed) account for messages, opened and tried to delete attachments.
> I then noticed the message was duplicated in the folder but only the original message had a large size.

It sounds that problem of "\Deleted flag is not stored to original" consistently occurs.
"Why I could see phenomenon several times but I couldn't see phenomenon usually" was perhaps:
- Tested with Offline-Use=Off with small/faked mp3 file, so, sometimes entire mail data is held in Disk Cache, but sometimes not.
- I usually show Real Folder(Search  target folder) at Folder Pane, and last selected mail is shown at message pane.
- I changed IMAP delete model someties wfile Tb is running.
I tred to remove such conditions, and I could observe phenoenon repeatedly.
   Use Offline-Use=On folder. Don't open Real Folder(Search target folder). Restart Tb if I changed IMAP delete model.
[Steps to reproduce]
0. Don't use Gmail IMAP, Offline-Use=On folder, Real Folder is sync'ed, "Open message in existing window" option.
    IMAP .Delete model=Move to trash, or IMAP .Delete model=Just mark it as deleted
    Select other than the Real Folder, then terminate Tb.
    No Search Folder(Virtual folder) which has the Real folder as "search target follder".
1. Restart Tb => Real folder is not selected at folder pane(Real folder is not opened)
2. Seaarch messages -> Open a mail -> at message window, Delete Attachment
    => attchment is not deleted at message pane. messae window is still kept open, with original mail shown.
    => At SearchDialog, nothing is changed(number of mails, size column etc. is not changed)
3. At SearchDialog, repeat "Open a mail, Delete atachment" (N-1) times.
    Because of "Open message in existing window", window is re-used.
4. Open Real Folder(Search target folder) => N mails are duped. 
    One mail is original mail, another is "attachment deleted" version.
5. At Real folder, "Repair Folder" => nothing is changed. i.e. "\Deleted flag" is not stored by Tb.
I could see phenomenon which I reported to comment #6 cosistently, at last.

"IMAP delete model != Remove immediately", so "store +Flags(\Delete)" is not issued if message window is opened from SearchDialog?
Or "store +Flags(\Delete)" is requested to "msgFolder associated to gFolderDisplay/gDBView at message window == Virtual Folder if opened from SerchDialog/Search Folder" instead of "msgFolder assciated to shown msgDBHdr == Real Folder where the message is held"?

Comment 14

[WADA:World Anti-bad-Duping Agency]

Attachment: NSPR log(imap:5,msgCopyService:5) of Delete Attachment at messageWindow opened by Virtual Folder and Real Folder

NSPR log with IMAP delete model=Just mark it as deleted.

Difference observed by log is following only.
(A) If message window is opened from Virtual Folder(Search Folder), "store flag \Deleted" is NOT issued for original mail.
(B) If message window is opened from Reaal Folder, "store flag \Deleted" is issued. for original mail.

After normal end of "append" of new version, following error is seen in both cases.
> 00000221 [3828] 0[100f140]: CopyNextStreamMessage: Copying 1 of 1	
> 00000222 [3828] 0[100f140]: NotifyCompletion - src  dest imap://[e-mail]/F0/F1	
> 00000223 [3828] 5572[10118a0]: CopyNextStreamMessage failed:80004002	
> 
> 00000609 [3828] 0[100f140]: CopyNextStreamMessage: Copying 1 of 1	
> 00000610 [3828] 0[100f140]: NotifyCompletion - src  dest imap://[e-mail]/F0/F1	
> 00000611 [3828] 1832[1011360]: CopyNextStreamMessage failed:80004002	

"Delete Attachment" looks : (i) Generate new version of mail internally, (ii) Move it to Real Folder, (iii) Delete original.
I can guess other difference than "msgFolder pointed by gFolderDisplay/gDBView".
Phenomenon like following?
- Above error somehow occurs after "append" of new version.
- If msgFolder pointed by gFolderDisplay/gDBView is Real Folder && msgFolder pointed by msgDBHdr=Real Folder, 
  or if msgFolder pointed by gFolderDisplay/gDBView(IMAP Real Folder) === msgFolder pointed by msgDBHdr(same IMAP Real Folder),
  the error is  processed, then "store flag \Deleted" is issued.
- If msgFolder pointed by gFolderDisplay/gDBView is Virtual Folder && msgFolder pointed by msgDBHdr=IMAP Real Folder, 
  or if msgFolder pointed by gFolderDisplay/gDBView(Virtual Folder) !== msgFolder pointed by msgDBHdr(IMAP Real Folder),
  the error is not processed well, then "store flag \Deleted" is NOT issued.

Comment 15

[WADA:World Anti-bad-Duping Agency]

FYI.
80004002 found in comm-central.
> http://mxr.mozilla.org/comm-central/source/mozilla/xpcom/base/ErrorList.h#17
> 16   /* Returned when a given interface is not supported. */
> 17   ERROR(NS_NOINTERFACE,                         0x80004002),

Comment 16

[WADA:World Anti-bad-Duping Agency]

FYI.
"CopyNextStreamMessage" in comm-central.
> http://mxr.mozilla.org/comm-central/search?string=CopyNextStreamMessage&find=&findi=&filter=^[^\0]*%24&hitlimit=&tree=comm-central
Above error is logged at following line in nsImapProtocol::ProcessCurrentURL().
> http://mxr.mozilla.org/comm-central/source/mailnews/imap/src/nsImapProtocol.cpp#1845
>        rv = imapMailFolderSink->CopyNextStreamMessage(GetServerStateParser().LastCommandSuccessful() &&
>                                                  NS_SUCCEEDED(GetConnectionStatus()),
>                                                  copyState);
>        if (NS_FAILED(rv))
>          PR_LOG(IMAP, PR_LOG_ALWAYS, ("CopyNextStreamMessage failed:%lx\n", rv));

Comment 17

[WADA:World Anti-bad-Duping Agency]

Phenomenon seems following.
1. To CopyMessage request for upload new verson, 0x80004002 error is returned.
2. After it, fetch of header for the uploaded new version is requested.
3-a. If View at Real folder, Thread Pane/View is refreshed with the new version,
       so "delete original" is requested after Detach/Delete, then "store + Flgs(\Deleted)".is issued for originaal.
3-b. If View is SearchDialog/Serch Folder, Thread Pane/View is not refreshed with the new version.
        Only "Update of existent mail in a Search Result" is done, because this is ."SearchDialog/Serch Folder".
4-a. If View at Real folder, "\Deleted status of original" is detected, 
       so, end of "Upload new version + Delete original" can be known, then referesh of message window is possible.
4-b. If View at at Real folder, "new version" is not reflected to View"  because this is ."SearchDialog/Serch Folder". 
        - Just matk it as deleted
          HdrDeleted even doesn7t occur, even when "uid store original +Flags(\Deleted)" is issued.
        - Move to Trash
          Because of Detach/Delete, "move to trash" is not executed.
          Because of this bug,  "store +Flags(\Deleted") is not executed, So,  HdrDeleted event won't occur.
       So, even if "uid store original +Flags(\Deleted)" is issued by Detch/Delete,
       message window is not refereshed after Detach/Delete at message window.

Change like following may be needed.
   If action like "kill myself", 
   1. Refersh View even if SearchDialog/Search Folder(do Search again automatically),
   2. At message window, if currently shown mail's status is chaned to "flag \Deleted",
       even when HdrDeleted event is not invoked for the currently shown mail',
 .     2-a. if  "open in new message window", close message window,
               And if Detach/Delete like action which is "kill myself+regenerate myself", show myself aagain if required.
 .     2-b. if  "open in existing message window", 
               if Detach/Delete like action which is "kill myself+regenerate myself", show myself again or advance to next mail.
Neeedless to say, error of 0x80004002 should be resolved, and error handling in nsImapProtocol::ProcessCurrentURL().and imapMailFolderSink->CopyNextStreamMessage should be improved.

Comment 18

[WADA:World Anti-bad-Duping Agency]

Attachment: NSPR log(imap:5,msCopyService:5) for Attachment Delete at message Pane of Real IMAP folder

Following error occurs  after "append" of new version, even when Attachment Delete at message Pane of Real IMAP folder.
> 00000221 [3828] 0[100f140]: CopyNextStreamMessage: Copying 1 of 1	
> 00000222 [3828] 0[100f140]: NotifyCompletion - src  dest imap://[e-mail]/F0/F1	
> 00000223 [3828] 5572[10118a0]: CopyNextStreamMessage failed:80004002	
However, after header fetch of the newly uploaded version, "uid store NN +Flags(\Deleted)" is normally requested.

Some problems are involved in this bug.
(1) 80004002 error
(1-1) If Detach/Delete is executed on IMAP mail, "CopyNextStreamMessage failed:80004002" error occurs.
      => Such error shouldn't occur.
(1-2) This error is never notified to user.
      => Such error should be notified to user, at least via. Error Console or Activity Manager.
(2) "store +Flags(\Deleted)" is not requested,
       if "Detach/Delete of IMAP mail" is executed at "message window opened by SerchDialog or Search Folder"
       with "Just mark it as deleted" or "Move to trash".
      -.If local mail folder, no problem.
      - If "message pane of Real IMAP folder", or if "message window opened from Real IMAP folder", "store +Flags(\Deleted)" iss requested.
      - If "Remove it immediately", no problem, because "store +Flags(\Deleted)" is executed and msgDBHdr is removed, then HdrDeleted ecent ocuurs.
      - Because "Detach/Delete Attachment" is never "Delete action of original mail", "move to trash" won't occur.
        So, there is no difference between "Just mark it as deleted" and "Move to trash".
        Both are "not remove immediately". So, HdrDeleted event won't occur even when "store +Flags(\Delete)" is normally requested.
    => "store +Flags(\Deleted)" should be executed after Detach/Delete of Attachment even if error of 80004002 happened,
          as normally executed if message window opened by Real IMAP folder" or "message pane of Real IMAP folder".
(3) Confusing behavior at "message window" when \Deleted flag is stored but msgDBHdr is not removed(ordinal state in "Just mark it as deleted").
      Because mail of "flagged as \Deleted but msgDBHdr exists" is never deleted mail, Edit, Detach/Delete etc. can freely be executed on mail.
      Because HdrDeleted event won't occur, original mail is still shown even after Detach/Delete of Attachment.
      This is irrelevant to opener of the message window. Real Folder or Search Folder or SerchDialog is irrelevant.
      If "Detach/Delete of Attachment" is  executed at message pane of 3pne window, message pane is updated by new version.
      => Feed back of "Detach/Delete of attachment completed" should be done even if it's independent message window/Tab,  as done in message pane.
            Even if \Deleted flg is stored by other one, it's curently propagated to any Virtual Folder(Search Folder) and SeaarchDialog properly. 
(4) Sligtly confusing behavior at "message pane" on mail of "flagged as \Deleted but msgDBHdr exists".
      Even though "Attachment Detached/Deleted" version is shown at message pane just after Detach/Delete operation,
      old version(shown with trash icon, strike-thru line at Thread Paane) can be viewed at ny place as "active mail".
      So, user can view original multiple times, then user user can do Detach/Delete multiple times on original mail.
      Thus, duplicated mails cn increase infinitely.
      => "Detach/Delete" should be prohibited if \Deleted flaag is already stored.
             State of "\Delete flaag is stored" should be shown at messge pane and message window.

Comment 20

[jwq]

Thunderbird/38.3.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0)

I see the same bug with a Dovecot server accessed by IMAP, with the marginally new information that it appears for messages accessed through a saved search as well.

 Just to be clear: detach/delete of an attachment creates a new message on the server with the attachment removed (correct) but does not delete the original message from the server (incorrect), no matter what setting I have for "When I delete a message" (move/mark/immediately).

Comment 21

[Matthias St. Pierre]

(In reply to hippiefreak from comment #0)

User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; Trident/7.0; SLCC2; .NET CLR
2.0.50727; .NET CLR 3.5.30729; .NET CLR 3.0.30729; Media Center PC 6.0;
.NET4.0C; .NET4.0E; BRI/2; rv:11.0) like Gecko

Steps to reproduce:

I perform Shift-Control-F to open the Search Box. I search and find emails
ok. I double-click on any email in the Search results, it opens just fine.
If the email has attachments, I elect to remove the attachments by first
right-clicking on the word "attachments" in the bottom status bar of the
opened email. I select "Delete All" from the little menu that results. A
pop-up appears, listing the attachments and advises me the deletion is
permanent; do I wish to continue? I click Yes.

Actual results:

The attachments do not delete.

I can confirm that the above issue still occurs with my IMAP account. But there is one important detail to add to the above description: Although it seems that nothing has happened, that is not the case: The removal of the attachments is in fact successfull, however, the stripped message is stored as a duplicate message with the same timestamp as the original message, and the original message remains unchanged. This happens only if the message was opened from the search box (Shift-Control-F), which happens to me frequently, because I use the search box to locate messsages with large attachments when my IMAP account gets too full. If I navigate to the folder where the message is located, the deletion of the attachments works as expected.

This issue seems to be present for at least 10 years already and has been reported several times, see Bug 1299774 and Bug 518891. There seems to be also some similarity with Bug 1106225.

Name: Thunderbird
Version: 60.5.0
Build-ID: 20190122170039

Update-Kanal: release
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.5.0
Betriebssystem: Windows_NT 10.0

Comment 25

[Alex Ihrig [:Thunderbird_Mail_DE]]

There are reports confirming the problem in german support forums.

Additionally I've the problem with duplicated messages after detaching, when the detach process is startet from outside the processed messages folder. This is not only the case, when detaching from a saved search folder. The same is, when using / experimenting with my "AttachmentExtractor Continued" addon. This addon has an automatic detach feature. Running the automatic detach feature, when the focus in 3-pane-window is not in the processed messages folder, leads to the described duplicated messages.

Comment 26

[Alex Ihrig [:Thunderbird_Mail_DE]]

Unfortunately, this bug also affects the MailExtension API event "onNewMailReceived". This event is fired again if the original messages in the IMAP folders are not deleted.

So it would be doubly important that this bug is fixed.

Comment 27

[brendel oliver]

I cannot confirm this bug anymore : I searched using CTRL-F for emails, opened emails with an attachment, deleted the attachment from the message window. I then checked in the original folder : the email had well been deleted. I checked for emails in the IMAP inbox and in local folders. TB 91.7.0 32 bits, on windows 10.

Comment 28

[brendel oliver]

well, It seems that I need to reconfirm the bug,attachments from emails opened from the CTRL-F search window do neither delete nor detach.
102.3.3 (32 bits) windows 10

Comment 29

[Matthias St. Pierre]

It seems to be a never ending story… I gave up using this feature long time ago :-/

Comment 30

[hippiefreak]

(In reply to Matthias St. Pierre from comment #21)

(In reply to hippiefreak from comment #0)

User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; Trident/7.0; SLCC2; .NET CLR
2.0.50727; .NET CLR 3.5.30729; .NET CLR 3.0.30729; Media Center PC 6.0;
.NET4.0C; .NET4.0E; BRI/2; rv:11.0) like Gecko

Steps to reproduce:

I perform Shift-Control-F to open the Search Box. I search and find emails
ok. I double-click on any email in the Search results, it opens just fine.
If the email has attachments, I elect to remove the attachments by first
right-clicking on the word "attachments" in the bottom status bar of the
opened email. I select "Delete All" from the little menu that results. A
pop-up appears, listing the attachments and advises me the deletion is
permanent; do I wish to continue? I click Yes.

Actual results:

The attachments do not delete.

I can confirm that the above issue still occurs with my IMAP account. But there is one important detail to add to the above description: Although it seems that nothing has happened, that is not the case: The removal of the attachments is in fact successfull, however, the stripped message is stored as a duplicate message with the same timestamp as the original message, and the original message remains unchanged. This happens only if the message was opened from the search box (Shift-Control-F), which happens to me frequently, because I use the search box to locate messsages with large attachments when my IMAP account gets too full. If I navigate to the folder where the message is located, the deletion of the attachments works as expected.

This issue seems to be present for at least 10 years already and has been reported several times, see Bug 1299774 and Bug 518891. There seems to be also some similarity with Bug 1106225.

Name: Thunderbird
Version: 60.5.0
Build-ID: 20190122170039

Update-Kanal: release
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.5.0
Betriebssystem: Windows_NT 10.0

Hi, this is OP. Yes, the above important detail was omitted by me. The problem as identified in the OP and as augmented above is still occurring. It's now December 2023. Merry Christmas, everyone!

Comment 31

[Matthias St. Pierre]

Hi @hippiefriek,

merry Christmas to you as well. I donated 20€ to Mozilla this year. Hopefully they will us the money to fix our bug. :P

Comment 32

[Matthias St. Pierre]

*use

Comment 33

[Matthias St. Pierre]

And btw @hippiefriek: your initial conversation with @WADA from 9 years ago still makes me chuckle 😂

Comment 34

[hippiefreak]

@Matthias St. Pierre,

If you'd like another chuckle, consider that my hair is now gray since 9 years ago. In another 9 years I could be dead and then my problem with these attachments will be solved. LOL.

Seriously, it appears that this is a low-priority issue suggesting that few users encounter the need to delete attachments from emails found through the Search Box. I, however, manage a highly active hobby website where people send me attachments regularly and I only delete them much later after research for my website caused by those attachments has been completed. This can take months or sometimes years. This causes me to constantly use the Search Box by necessity to find these old emails to want to then delete the attachments I've found, to recover storage space. So, I encounter this issue almost every day that I am managing my site. After 9+ years the workaround for this is now its own procedure but it would be nice if it got fixed.

Comment 35

[clubs]

Can I just add that I find the same issue - when I delete an attachment from a message viewed in a saved search folder I end up with the original and the copy with the attachment deleted. If I do the same from the IMAP Inbox folder everything works correctly and I no longer have the original message. Was going to raise a new issue - but found this one which seems to be the same bug.

Obviously the workaround is not too onerous, but since I typically only view the saved search folder (which includes messages from all my inboxes) this is a bit of an annoyance.