231846 - Delete bug in thread view

Status: RESOLVED FIXED

(Thunderbird :: Mail Window Front End, defect)

Description

[bart decrem, not checking bugmail]

Often, but not always, if I'm in Thread view and delete messages in the thread,
I get the following behavior:

Before:
- Thread posting 1
-- Thread posting 2
--- Thread posting 3

Then I delete posting 1 and I get:

After:
- Thread posting 2
-- Thread posting 2
--- Thread posting 3

With the second entry being a ghost entry: clicking on the message doesn't show
any content.

Comment 1

[Anthony R. Thompson]

System: Windows 2000
Thunderbird version: 0.4
Reproduceable: Unfortunately, no
Related bugs: 216310 and 231846  (maybe; they sound similar)
User: Anthony R. Thompson, [e-mail]

Summary: First-time (after install) expanding & contracting a thread caused one
message per expansion/contraction to seemingly disappear from the mailbox;
switching to another mailbox and coming back "restored" the messages and the bug
was not reproduceable.

Detail: I experienced a similar bug to this one.  Fresh install of Thunderbird
0.4 today, the first time I clicked the "Click to display message threads" icon,
it seemed to work fine (the one thread in the mailbox was displayed properly,
expanded).  I deleted the first message in the thread but changed my mind, so I
did ctrl-Z (undo).  However, when it came back it had the same subject etc. as
the second message in the thread.  Then when I collapsed the thread (hit the -
box), one of the messages in the thread just disappeared.  When I expanded the
thread (hitting the + box), a message below the thread disappeared.  Every time
I toggled the thread +/- box, another message disappeared.

I went to a different mailbox and came back, and all the messages were restored
(including the original two message thread).  When I tried to reproduce it, I
was unable to do so.  I tried reproducing it in the original mailbox and a few
other mailboxes, but threading now seems to work fine.  I tried closing
Thunderbird and re-opening, to reproduce it, but was unable to.

Comment 2

[bart decrem, not checking bugmail]

I'm still experiencing this in 0.7 on OSX.  Not sure how to nominate this as a
blocker, so I just set a target milestone for this to 0.8.  I hope that's OK,
since this bug really interferes with usability, at least for me.

Comment 3

[Alexander Sascha Fichtner]

System: Windows 2000
Thunderbird version: 0.7+ (20040712)
Reproduceable: yes

Maybe not quite the same bug, but might be related...

I also experience some strange behaviour related to thread sorting. I was able
to reduce this reproducible case to exactly one thread in one of my folders.
Sorting is set to "Date/Ascending/Threaded" and the thread is unfolded.

This thread should contain 5 mails (i.e. one original and 4 follow-ups). Only
the original and the first follow-up are displayed.

As soon as I manually close this thread the whole thread simply disappears and
won't come back until I switch to another folder and back. Changing the view to
e.g. "Sorted by date" will show all the thread's mails, so these mails only
disappear from the threaded view and not altogether from the folder.

I also have a testbed with some more threads (chronologically after this "bad"
thread). Whenever collapsing/expanding the first (bad) thread, parts of the
subsequent threads seem to get swallowed and disappear.

But after manually moving some of the thread's follow-ups to another folder and
back suddenly everything works as expected, all the time.

Comment 4

[David :Bienvenu]

Bart, do you use IMAP or POP3? Are you viewing all messages, or just unread? Are
your threads sorted normally (i.e., with oldest threads first?). Do you ever use
Windows builds, and if so, do they have this problem?

Comment 5

[David :Bienvenu]

Attachment: proposed fix

After talking to Bart, we decided it's quite possible that this happens when he
undoes a delete - he undoes and redoes deletes very often. What happens is that
the msg hdr we undo the delete for already has a thread parent set, when we
pull it out of the undo queue - this needs to be cleared so that we'll figure
out the thread parent correctly....

Comment 6

[David :Bienvenu]

Comment on attachment 155089 [details] [diff] [review]
proposed fix

probably lots of dups of this bug.

Comment 7

[Scott MacGregor]

Comment on attachment 155089 [details] [diff] [review]
proposed fix

bart will be so happy.

Comment 8

[bart decrem, not checking bugmail]

this will change my life :)  david and I just ran through an occurrence of this
bug.  hopefully we're one step closer.  

Comment 9

[David :Bienvenu]

Attachment: another fix

I believe the view counts could also get off when a new message gets added as
the parent of an already open thread - this scenario was generating an assert
in the tree code. This patch fixes that by making sure we notify the tree about
the insert of the new top level message. I'm not sure if this could cause the
problem Bart sees, but it's not good for the count to get off.

Comment 10

[David :Bienvenu]

Bart, can you try tomorrow's tbird build (trunk or branch, either one) and let
me know if you still see this? I'm not sure if either of these fixes will get
rid of what you saw, but it's worth a try.

Comment 11

[Alexander Sascha Fichtner]

version 0.7+ (20040807)

I still see the bug as described above. Should I file a separate bug report as
this seems to be a slightly different problem? Please advise. :)

Comment 12

[bart decrem, not checking bugmail]

i'm running the 8/5 build and haven't seen the threading bug yet.  I'll let you
know if I encounter it again.  i'm hopeful.

Comment 13

[David :Bienvenu]

Bart has not seen this in a week - marking fixed, tentatively...

Comment 14

[David :Bienvenu]

re-opening - Seth and I found another problem in this area...patch upcoming

Comment 15

[David :Bienvenu]

Attachment: another fix

this fixes a problem I see when opening a folder that's sorted flat (e.g., by
date or subject) and then switching to threaded mode. Some messages are
indented that shouldn't, and some don't have thread icons that should
(seemingly). This patch fixes the indentation. I'm not sure if this fixes the
delete problem, but it fixes the bogus indentation (not sure why the code as it
was doesn't work - that's another thing I need to figure out)

Comment 16

[David :Bienvenu]

Attachment: fix for Seth's reproducible case

yet another fix - this fixes the case where new headers arrive into a
flat-sorted folder (e.g., by subject) after the folder is opened, and then we
switch to threaded view. Sometimes we weren't noticing that the new header
arrivals made one or more of the threads into threads with children, and things
degenerated from there.

Comment 17

[David :Bienvenu]

Attachment: trunk version of fix

this fixes the problem on the trunk.

Comment 18

[David :Bienvenu]

fixed on trunk.

Comment 19

[[e-mail]]

Comment on attachment 159587 [details] [diff] [review]
trunk version of fix

>+      if (numExpanded > 0)
>+        m_flags[j - numExpanded] = flags | MSG_VIEW_FLAG_HASCHILDREN;

This part of the patch is unnecessary because it's in an if block that has
already checked for the MSG_VIEW_FLAG_HASCHILDREN bit.

Comment 20

[Mike Cowperthwaite]

*** Bug 252572 has been marked as a duplicate of this bug. ***