First, I'm not certain if "Mail Window Front End" is the proper component to classify this under. I'll leave it up to those who know more about it to decide that :) Here's how to reproduce my problem (the problem is explained in the reproduction): 1. You need a mailbox set up as follows: A. At least one message with a _single_ reply to it. With more than one reply, everything behaves correctly. I will refer to the parent message as "P" and the reply to it as "R". B. The mailbox must be sorted by thread so that R is a child to P. C. There must be at least one other message in the mailbox from a different thread listed below P and R. 2. With the message tree closed (so that P is visible, but not R) delete P. R should now appear. 3. Now, hit ctrl-z to undo the deletion. The message under the cursor is replaced by P and the right pointing arrow on the left side re-appears indicating that there is a child. 4. Press the right cursor arrow. The arrow on the left switches to point down as if a thread is being expanded, but R does not appear beneath it. 5. Press the left cursor arrow to close the thread. Now, the arrow next to P reverts to pointing left (as it should), and the message below P disappears (as if it was sucked into P's thread.) Now, if you try to expand P's thread again, the same thing happens and you can eliminate every message after P this way.

Hmm... I just tried this. It took me a couple tries, but I see the problem. Also, if not using the arrow keys, you can get into other not-so-disastrous states which seem to vary. In those cases it appears that once you undo the deletion, even when the undeleted message appears it will never again thread back to the parent when in threaded mode -- it is now a separate thread.

By the way, I saw this with Aug06 commercial trunk build, win98.

This problem seems to vary in its results... sometimes when using the mouse to click for expand and collapse I see the drastic problems and sometimes the undeleted message appears. If you perform the steps on a thread with several replies, it seems to replicate the replies instead of removing them/sucking up the next messages in the list.

I just hit this again and it messed with my mind. I think we should handle undo of deletion of a collapsed parent more smooothly. nominating

This problem still exists on 2001-12-14-06 build on win98

Is this really a nsbeta1+, P2? If yes, then we need to try and targeted to a milestone M1.0 or earlier to make the beta.

nsbeta1- per ADT triage, ->1.2, blocks 'miracle bug' 122274

This still appears to be a problem in the final release of Mozilla 1.0, since I just lost a message from my INBOX...this is a serious problem.

Nominating nsbeta1.

Mozilla 1.1b nightly build Mozilla/5.0 (X11; U; SunOS sun4u; en-US; rv:1.1b) Gecko/20020901 anyway, I do not lose the P and R message as this bug expected. But in the message db view ( the area in which mozilla shows all msg'e headers), the msg's header is not correct.

Mail triage team: nsbeta1+/adt3

taking - I'll try to recreate this

the only problem I see remaining is that we don't refresh the msg pane with the newly undeleted message. Does that correspond with what everyone else sees?

(In reply to comment #13) > the only problem I see remaining is that we don't refresh the msg pane with the > newly undeleted message. Does that correspond with what everyone else sees? David, I'm sure this is happening. When I click another mail first and then return to the undeleted mail it is displayed correctly. We only have to refresh the messagepane. The same bug also exists in Thunderbird version 1.0 (20041206).

backend issue?

yes, the problem is most likely in nsMsgDBView.cpp, or nsMsgThreadedDBView.cpp

Still present on 3.0b2pre (I was filling another bug when I found this one).

flod, eric, Tony, can you reproduce comment 0 using version 3.1 or current trunk? using current trunk I don't see the comment 0 behavior. but I do see comment 13, "We only have to refresh the messagepane" (preview pane)

(In reply to comment #21) > using current trunk I don't see the comment 0 behavior. but I do see comment > 13, "We only have to refresh the messagepane" (preview pane) AFAIK comment 0 can't happen anymore in Thunderbird, since when you delete the first message of a collapsed thread the entire thread is deleted. I still see issues when deleting single messages from an expanded thread, so comment 13 is still valid.

(In reply to comment #23) > (In reply to comment #21) > > using current trunk I don't see the comment 0 behavior. but I do see comment > > 13, "We only have to refresh the messagepane" (preview pane) > > AFAIK comment 0 can't happen anymore in Thunderbird, since when you delete > the first message of a collapsed thread the entire thread is deleted. I > still see issues when deleting single messages from an expanded thread, so > comment 13 is still valid. thread delete will indeed happen if the collapsed thread preference is enabled (which is by default). But it is possible for people (like myself) to disable that preference :)

is this partly a listener issue as well? dupes? https://bugzilla.mozilla.org/buglist.cgi?query_format=advanced&short_desc_type=allwordssubstr&resolution=---&type0-0-0=nowords&value0-0-0=count%20counts&product=MailNews%20Core&product=Thunderbird&short_desc=undo%20list&list_id=7909140