318954 - Delete Attachment moves email to bottom of thread window

Status: NEW

(Thunderbird :: Mail Window Front End, defect)

Description

[Shawn Devlin]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.8) Gecko/20051111 Firefox/1.5
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.8) Gecko/20051111 Firefox/1.5

When viewing email by threads, deleting an attachment on the first email in the thread moved the email to the end of the thread chain.

Reproducible: Always

Steps to Reproduce:
While in threaded email view:

1. Select email with attachment
2 [review]. Right click attachment and choose delete

Actual Results:  
Email with attachment moved to bottom of thread

Expected Results:  
Email should stay in the same place in the thread

Comment 1

[gaele]

I experience the same in 1.5 RC1 (Win XP).

Comment 4

[Steve Simms]

Confirming.  This is the same problem as when the list is sorted by "Order Received".  This happens in IMAP and POP3 because the protocols don't support modifying messages, as far as I know, so the only way to delete an attachment is to create a new message and delete the first one.

But, as far as the user is concerned, the message *should* stay in the same place, and it's confusing that it doesn't.

One way around it would be to recreate all E-Mails subsequent to the one with the deleted attachment as well, but that would be impractical for a large mailbox, and/or a slow Internet connection.  I can't think of any other way that would work across multiple E-Mail clients.

So, this may need to be a WONTFIX, unless there's an easier way of keeping the message in the same place on the server.

Comment 5

[WADA:World Anti-bad-Duping Agency]

This bug is combination of 2 phenomenon.
(A) Current detach/delete of attachment is "(a) creation of new mail with
    detached/deleted attachment + (b) deletion of original mail".
    (this is similar to "move to other local mail folder then move back")
    "Order Received" column:
       Local mail folder(POP3,Local Folders): offset in mail folder file.
       IMAP: UID of mail.
    When POP3, new mail's offset becomes largest, because appended to file.
    When IMAP, new UID is generated by IMAP, so new mail's UID becomes highest.
(B) When threaded view, new mail is displayed at bottom.
    Re-threading is probably not automatically done upon new mail detection.

(B) is already reported phenomenon by other bug.

(For phenomenon A)

When local mail folder file(POP3) and "detach/delete of attachment", offset can technically be kept by following.
(1) Overwrite of part for attachment data, instead of new mail.
    Replace attachment part data without part length change(padding with null
    lines), if new part data(detached/deleted) length is shorter than original.
    If new part data length is longer than original, create new mail data
    as currently done.
   (note: overwrite is already done on X-Mozilla-Status(2): & X-Mozilla-Keys:) 
(2) Enhancement of "Compact Folder" of local mail folder file.
    Invoke Compact folder even if no deleted-but-not-expunged-yet mail,
    if detached-or-deleted-attachment exists, and if part for "detached/deleted
    attachment" is detected, remove padded lines.
    (note: Special action in "Compact Folders" is already implemented)
    (      1. addition of X-Mozilla-Status:/X-Mozilla-Status2: if not exists)
    (      2. addition of X-Mozilla-Keys: if not exists                     )
When IMAP, there is no way, because IMAP doesn't have option to replace mail data.

However, number in "Order Received" column(offset in file when local mail folder, UID of mail in mail folder when IMAP) always varies upon copy/move of mail. Number in "Order Received" column can be used as "Order Received" only when no move/copy is involved.
We already have many accounts/many mail folders, and we daily move mails by message filter/junk filter/manual move for arrangement of mails.

"Keep offset value only when detach/delete of attachment and only when local mail folder" is valuable/mandatory feature?
The column name is provided during "only single account/only single mail box" era, I believe.

(To bug opener of DUPed bug)
If "Order Received" is important for you because many mails have incorrect timestamp(Date:) due to incorrect timer setting of mail sender's PC or spammer's intentional future Date:, new feature of Tb 3, "Received" column(Received: header. Server's timestamp when the mail arrived at server. Outlook Express already has.) can be used as "Order Received" for you.