367689 - The first message of the next thread is selected when deleting a message and folder automatic compact occurs

Status: NEW

(Thunderbird :: Folder and Message Lists, defect)

Description

[Frédéric Buclin]

Thunderbird version 2 beta 2 (20070118)

If your thread pane displays messages grouped by threads and sorted by date (from older to newer) and if you delete a message from a thread and automatic folder compression occurs, then the first message of the next thread is selected instead of the next message in the current thread. This is problematic if the message you deleted is the first one of the thread, because the automatic compression will reorder threads by date, and it may not remain right before the new selected thread. It's then hard to find the thread you were reading, especially if there is no new messages in this thread.

For the record, this behavior occurs since the checkin of bug 362241.

Comment 1

[Scott MacGregor]

Moving off bugs that didn't make the deadline for Thunderbird 2. 

Comment 2

[Jason Merrill]

This seems related to an issue I've been having: I have Thunderbind set to mark messages as deleted rather than move them to another folder, and if I have collapsed threads like

-> + thread 1
   + thread 2

and I hit delete, Thunderbird deletes the first message in thread 1 and then moves to thread 2:

   + --thread 1--
-> + thread 2

which skips past the rest of thread 1, but leaves it undeleted.  I want it to move to the next message in thread 1 like it does when moving deleted messages to the Trash.

Also, if I hit delete but the delete takes some time to process, so I move around in the mailbox manually, when the delete finishes Thunderbird moves the cursor to the next message after the deleted message; this makes sense if the cursor is still on the deleted message, but is annoying if I'm already looking at a different message.

Comment 3

[Wayne Mery (:wsmwk)]

is this also seen in version 3? 
(I expect yes, but worth knowing that someone checked it)

Comment 4

[Frédéric Buclin]

From what I just experienced in Tb3.0, the selection goes away, which is not better.

Comment 5

[Wayne Mery (:wsmwk)]

(In reply to comment #4)
> From what I just experienced in Tb3.0, the selection goes away, which is not
> better.

related to bug 479064?

Comment 6

[Frédéric Buclin]

(In reply to comment #5)
> related to bug 479064?

yes

Comment 7

[Wayne Mery (:wsmwk)]

per comment 0, "For the record, this behavior occurs since the checkin of bug 362241 (fixed in v2, 2007-01-09)."  Fairly disruptive, and increased frequency since we made auto compact the default in TB5.

several duplicates coming up. And others were already duped to bug 479064

Comment 13

[Wayne Mery (:wsmwk)]

FTR, anything reported prior to on development branch for v3 prior to  2009-10-16 could be Bug 509748 - Message list for Inbox blanks until manually selecting another folder to view (IMAP folder, after "Compact") - and not this bug.