517727 - Deleting/detaching attachments moved message down on threaded view

Status: RESOLVED DUPLICATE of bug 318954

(Thunderbird :: Folder and Message Lists, defect)

Description

[Henry N.]

User-Agent:       Mozilla/5.0 (X11; U; Linux x86_64; de; rv:1.9.1.2) Gecko/20090730 SUSE/3.5.2-2.1 Firefox/3.5.2
Build Identifier: Mozilla/5.0 (X11; U; Linux i686 (x86_64); de; rv:1.9.1.4pre) Gecko/20090915 Thunderbird/3.0b4

If deleting/detaching an attachment from first of two mails in threaded view, then they are swapped after deleting/detaching. A click to open/close this tread makes the second mail unreadable (is hidden).

Example for threaded view:
+ Message A with attachment
+--- Message B without attachment

After deleting/detaching attachment from message A:

+ Message B without attachment
+--- Message A with attachment

After clicking the (+) on Message B two times, Message A will not see again.


Reproducible: Always

Steps to Reproduce:
1. Have threaded view enabled
1. Have one message with attachment
2 [review]. Have an "answer" from 1. without attachment
3 [review]. Deleting or detaching attachment from 1.
Actual Results:  
Message 1 and message 2 are swapped in view.


Expected Results:  
Unchanged view order.


You can fix the view by leaving this folder and go back to this folder again.

Comment 1

[David :Bienvenu]

hmm, is message B a true reply to to message A? Can you create a test case by putting a couple messages that exhibit this problem into their own folder, make sure the folder reproduces the bug, and attach the folder to the bug, removing anything you don't want public first? (Or send me the test case folder directly.)

Comment 2

[Henry N.]

Attachment: Folder with 4 messages with attachment + 4 answers of it

The folder contains a folder with 4 messages with attachments and an answer to every of this mail. All 4 messages have this problem.

For testing:
1. Make sure the folder is in threaded view, older messages on top.
2. Select a message with attachment
3 [review]. Delete the attachment
4 [review]. Confirm the question about "can't revers ..."

After last step the message and the answer of it was swapped. You can see it by the send time, the icon "attachment" and on the subject line "Re: ...", that is now on top.

Create such messages by your self:
1. Create a message with attachment, send it to your self.
2. Answer to that message to your self back.
Now you can test it self, see steps above.

Comment 3

[Henry N.]

Attachment: Threaded view before delete attachment

Comment 4

[Henry N.]

Attachment: Threaded view *after* delete attachment

Watch, that in preview is seen the answer but the "Re:" is missing in the subject, and the time order is swapped now.

Comment 5

[Henry N.]

Attachment: After collapse this thread

After collapse this thread, the preview views the same message two times (see subject and date/time).

PS: You can't not explode this thread. It will only seen as single message from now. You can leave this folder and enter again, to have all in normal view. (No data are lost.)

Comment 6

[Henry N.]

(In reply to comment #5)
Be carefully with collapse and exploding these threads after the bug was seen. TB will crashing (without crashreporter) after you try to explode more of this bugged threads.

Comment 7

[Henry N.]

Mozilla/5.0 (Windows; U; Windows NT 5.1; de; rv:1.9.1.4pre) Gecko/20090915 Thunderbird/3.0b4

Windows has exactly the same problem.

Comment 8

[Wayne Mery (:wsmwk)]

iirc this still happens on trunk builds (and can be confirmed). do you agree?

Comment 9

[Joe Sabash [:JoeS1]]

Yes, still happens on current trunk.
Compacting the folder seems to correct the thread.

Comment 10

[WADA:World Anti-bad-Duping Agency]

(In reply to comment #9)
> Compacting the folder seems to correct the thread.

When detach/delete, "deletion of old version" and "addition of new verssion" happens. In this case, "Order Received" column value(offset in mail folder file if local mail folder, UID of mail if IMAP folder) is changed(incremented) by process of "deletion of old version and addition of new verssion".
If order in thread is affected by compact when mails of same subject instead of mails tighed by In-Reply-To: or References:, it may be relevant to nsIMsgIncomingServer::m_downloadedHdrs. See bug 618809 and bug 618809 comment #7, please. It may be relevant to bug 383985, because value of "Order Received(offset or UID) is currently afects on "order in thread", even though "order in thread" should be determined by Date: only.

Comment 11

[WADA:World Anti-bad-Duping Agency]

If affected by compact, it may be view refresh relevant issue, because thread pane is refreshed after compact. Is threading shown as expected by next?
1. At context menu of the folder, select "Open" and open new Tb window.
2. At the new Tb window, collapse thread, then re-expand thread.
3. At the new Tb window, go non-threaded view, then return to threaded view.

Comment 12

[WADA:World Anti-bad-Duping Agency]

In your case, root mail of thread is deleted and re-added or re-appended by detech/delete. Is same phenomenon observed by detech/delete of child mail(mail has no child mails)?

Comment 13

[WADA:World Anti-bad-Duping Agency]

Quick chack result with Tb 3.1.7, with test mails of Subject: Re: XXX, no In-Reply-To:/Reerences:, Date: mail-1=01:01, mail-2=01:02, mail-3=01:03.

(1) Thread is shown as expected by "Open" of new Tb window, and re-open of folder(click other folder and click folder again), even after this bug.
(2) At old Tb window, thread was not corrected by "go non-threaded view, then return to threaded view". Action of (1) was required.
(3) When "collapse thread, then re-expand thread", with delete of child mail and root mail, funny phenomenon was observed.
(initial)
  mail-1 = Re: XXX, 01:01 offset=0000
    mail-2 = Re: XXX, 01:02 offset=1000
    mail-3 = Re: XXX, 01:03 offset=2000
(delete of an attachment of mail-2==child)
  mail-1 = Re: XXX, 01:01 offset=0000
    mail-3 = Re: XXX, 01:03 offset=1000
    mail-2 = Re: XXX, 01:02 offset=3000
(collapse/re-expand of thread)
  mail-1 = Re: XXX, 01:01 offset=0000
    mail-2 = Re: XXX, 01:02 offset=3000
    mail-3 = Re: XXX, 01:03 offset=1000
(delete of an attachment of mail-1==root)
  mail-2 = Re: XXX, 01:02 offset=3000
    mail-3 = Re: XXX, 01:03 offset=1000
    mail-1 = Re: XXX, 01:01 offset=4000
(collapse/re-expand of thread)
  mail-2 = Re: XXX, 01:02 offset=3000
    mail-2 = Re: XXX, 01:02 offset=3000
    mail-3 = Re: XXX, 01:03 offset=1000
  => mail-1 is lost in thread, duplicated mail-2 in thread.
Action of (2) didn't show correct threading.
Action of (1) was required for expected thread display.

Comment 14

[WADA:World Anti-bad-Duping Agency]

Attachment: Mail folder file, 5 crafted mails with In-Reply-To:, 3 attachents for ease of repeated test

(In reply to comment #1)
> Can you create a test case (snip)

Quick observation.
(1) Mail is placed at bottom of thread after detach/delete, regardless of relation by In-Reply-To: header. "Root mail" or "child with no child" was irrelevant.
(2) If many detach/delete is executed in a thread for multiple mails, and if collapse/re-expand of thread is executed after detach/delete operations, some mails disappeared from thread, and were not shown at any place(some mails are lost in threaded view).
"Go non-threaded view, then return to threaded view" did not recover this "lost mail" status.
"Open other folder, then re-open the folder" was required to get correct threaded display again.

Comment 15

[WADA:World Anti-bad-Duping Agency]

After offset of mails were changed to random by detach/delete operations, phenomenon of "two threads at thread pane" was observed several times. It was not cleared even by "Repair Folder(including delete .msf)" and/or "Compact Folder" . "Searching for message-id of In-Reply-To:" looks affected by order in mail folder file(offset in mail folder file) and/or mail at offset=0(split of thread happns at mail of offset=0 in test case).

Comment 17

[Henry N.]

This bug still exist also in current version 45.8.0 (64 bit). The result is exactly the same.
IMAP or POP3 account makes no difference.

Example for threaded view of inbox:
+ Message A with attachment
+--- Message B without attachment

After deleting/detaching attachment from message A:

+ Message B without attachment
+--- Message A with attachment

After clicking the (+) on Message B two times (collapse and expand), Message A will not see again. The Subject B is view now two times:
+ Message B without attachment
+--- Message B without attachment

Reproducible: Always

Steps to Reproduce:
0. Have threaded view enabled
1. Have one message "A" with attachment
2 [review]. Have an "answer" from message "A" without attachment, use Subject "B"
3. Deleting or detaching attachment from message "A"

Actual Results:
Message "A" and message "B" are swapped in view.

Expected Results:  
Unchanged view order.

Comment 18

[Rolf Gloor]

This bug is still present in Thunderbird 60.2.1.

I receive a lot of eMails with attachements, Often with large attachements (Drawings, CAD-Data, etc.).
After storing on HD, I usually delete attachement in order to reduce size of (IMAP) eMail Account.
But keeping the eMails for documentation of the business communication thread.

Deleting attachement of child-eMails -> changing folders and switching threading on / off works for re-order correctly.
However, deleting an attachement of the root-eMail: the folders trick doesn't work.

This dis-order is confusing on a daily basis.