Open Bug 93923 Opened 20 years ago Updated 2 years ago

need thread pane refresh when deleting and restoring (undo) a parent message in a thread

Categories

(MailNews Core :: Backend, defect)

defect
Not set
normal

Tracking

(Not tracked)

People

(Reporter: jmerz42, Unassigned)

References

(Blocks 1 open bug)

Details

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.
Status: UNCONFIRMED → NEW
Ever confirmed: true
QA Contact: esther → sheelar
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. 
Summary: Messages lost when deleting and then restoring a parent message in a thread → Messages lost when deleting and then restoring (undo) a parent message in a thread
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
Keywords: nsbeta1
This problem still exists on 2001-12-14-06 build on win98
Keywords: nsbeta1nsbeta1+
Priority: -- → P2
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.
Status: NEW → ASSIGNED
Target Milestone: --- → mozilla1.0
nsbeta1- per ADT triage, ->1.2, blocks 'miracle bug' 122274
Blocks: 122274
Keywords: nsbeta1+nsbeta1-
Target Milestone: mozilla1.0 → mozilla1.2
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.
Keywords: 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. 
QA Contact: sheelar → gchan
Keywords: nsbeta1-
Mail triage team: nsbeta1+/adt3
Keywords: nsbeta1nsbeta1+
Whiteboard: [adt3]
Target Milestone: mozilla1.2alpha → ---
taking - I'll try to recreate this
Assignee: sspitzer → bienvenu
Status: ASSIGNED → NEW
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?
Blocks: 236849
Product: Browser → Seamonkey
(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). 

Severity: major → normal
backend issue?
Severity: normal → trivial
OS: Windows NT → All
Hardware: PC → All
Summary: Messages lost when deleting and then restoring (undo) a parent message in a thread → need thread pane refresh when deleting and restoring (undo) a parent message in a thread
yes, the problem is most likely in nsMsgDBView.cpp, or nsMsgThreadedDBView.cpp
Duplicate of this bug: 389460
Assignee: bienvenu → mail
QA Contact: grylchan
Assignee: mail → nobody
Component: MailNews: Main Mail Window → MailNews: Backend
Product: Mozilla Application Suite → Core
QA Contact: backend
Product: Core → MailNews Core
Duplicate of this bug: 135738
Still present on 3.0b2pre (I was filling another bug when I found this one).
Duplicate of this bug: 433320
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)
Severity: trivial → minor
Keywords: polish
Priority: P2 → --
Whiteboard: [adt3]
Duplicate of this bug: 671497
Severity: minor → major
Keywords: polish
(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 :)
Duplicate of this bug: 1464763
Severity: major → normal
You need to log in before you can comment on or make changes to this bug.