21469 - Deleting messages in thread view "hides" thread children

Status: VERIFIED FIXED

(SeaMonkey :: MailNews: Message Display, defect, P3)

Description

[Chris Waterson]

To reproduce:

1. Get a folder into "thread" view.
2. Click "Delete" at the head of a message thread.
3. All thread-children on the deleted message will vanish.

The thread children aren't -really- deleted; re-sorting or removing thread view
will reveal them.

Comment 1

[Chris Waterson]

This is not PDT+. I can use mail just fine without this being fixed.

Comment 2

[lchiang]

can I remove [DOGFOOD] then, waterson?

Comment 3

[Jim Roskind]

Note that ability to read email in threaded view *IS* dogfood.  IF you use that
style... but don't feel this is a stopper... then you can pull the dogfood and
PDT annotations.  If it stops you (or other "threader reading folks")... then
leave the annonations.

Comment 4

[pmock]

fyi,
I see this problem too using the commerical seamonkey builds, Win32 1999-12-11-
18-m12, linux 1999-12-11-08-m12, and Macos 1999-12-11-08-m12.  I was testing
under IMAP.

Comment 5

[leger]

Putting on PDT+ radar.

Comment 6

[scottputterman]

Nothing is being hidden.  As you mentioned earlier, it's the wonders of RDF that
is doing this. Say you have:

a
  b
  c
  d

And you delete a.  Well, then we have to remove b,c,d from a and then readd them
back in.  And of course they get added back in at the end.  Or, if you are
sorted, they get added back in where they are sorted.  Both of these give the
impression that something weird happened.

So, either I need a way in RDF to not reorder them like this, or I have to keep
track of everything myself and fake RDF out.  Or we can disallow the ability to
sort threads by anything besides thread id's and therefore I can just sort by
thread id and then it would work out.  Anyway, the part where I fake out RDF
requires more work then I think you want to hold dogfood for.

The only interesting thing I see here is that it looks like b,c,d are added to
the end whereas I would have thought it would become

b
 c
 d

at the end.

Comment 7

[scottputterman]

Please disregard my previous sarcasm about RDF.

I'm currently looking into what I need from RDF and the treeview to do this as
well as some other things for threads and views.  I will send out a message to
the relevant people when I've done so.  For those of you who are concerned about
this for dogfood, I'd like to design for all of the threading and view issues
that I know about rather than just this bug.  I imagine that it will take at
least a week or two to do this design and code it up.  If we want threading to
be useful, I think we'll need this for beta so I don't think this is any extra
work than previously planned.

Comment 8

[scottputterman]

A few more thoughts about this.

The problem we're seeing is due to the fact that when the tree is sorted,
deleting a thread parent might cause the rest of the thread to jump to some
place else in the tree to maintain the sort.

However, when we first start up there is no sort that's currently on.  So, the
first step for this bug might be to always have a sort.  I'll make the original
sort be the date since I think that is most common.

However, then threads will start jumping around due to the date changing.  The
next step would be to make the selection move to wherever the rest of the thread
went.  You'd lose the context where you were in, but at least the selection
would bring you to the correct next message.

There was some debate as to whether the thread child should stay where the
thread parent was or jump to where it would go in a sort. I think the final
decision was that it should stay were it is until the next sort or the next time
the folder is loaded.  This brings me back to the problem I originally stated
which is how to I make the sorting code not sort in this special case without me
having to manage everything myself.  I'm still thinking about this.

Comment 9

[scottputterman]

I think I have a plan. I think this pass will be to not make the messages stay
in place.  Instead I will allow the jumping around to occur but will scroll the
selection to the place where the rest of the thread shows up.  I think
eventually we will have to do the keeping in place, but I hope this will be
enough for dogfood.

Comment 10

[scottputterman]

Setting M13

Comment 11

[scottputterman]

I have the ability to navigate in threads.  Now, I just need the ability to
select the next message and scroll to the next message.  Alec is working on
12895 and 23204 which does makes it possible for the tree widget to handle this.
 Once these are done then I have to make the mail backend able to handle
selection and make it so that we scroll to the next message.

This is for the approach where threaded messages jump around due to the current
sort.  We also came up with a possible solution for keeping threads in the same
position regardless of the sort.  So if the first way turns out to be annoying I
will try that.

Comment 12

[leger]

Changing to pdt- per today's mtg and ok from phil.

Comment 13

[scottputterman]

need 23204.  marking M14.

Comment 14

[Paul MacQuiddy]

I am marking this beta1 cuz I don't think we can ship without it, although alec
says he can't fix 23204 for b1 :-(

Comment 15

[leger]

Moving [DOGFOOD] to keyword field as dogfood.

Comment 16

[leger]

Putting on PDT+ radar for beta1.

Comment 17

[lchiang]

I'e added comments into bug 23204 for phil and alec. There is a problem here if 
this bug is marked PDT+ and is dependent on a bug that alec says he can't get to 
for beta 1.

Comment 18

[scottputterman]

I'm pretty sure I have a fix so that the thread pane will scroll to the next 
message selected in the thread.  There are two other useability problems that 
I'm seeing. Right now when you delete a message, all of its children move up a 
level.  This means that if you delete a top level message, you are only going to 
follow one of the children.

If we fix that to do what 4.7 does then another problem will occur. The next 
message I currently pick is based on the sort whereas child promotion will 
probably be based on order received.  So it's possible it will select a message 
which isn't going to be the new top level message.

Comment 19

[scottputterman]

Marking this portion of the bug fixed.  Currently when you delete a message, you 
will be scrolled to the next message that is selected.  I checked this in. 
There is also bug 27688 which deals with some of the other problems I mentioned.

Comment 20

[esther]

Using commercial build 2000-02-16-16M14 on linux and win and 2000-02-16-08 on 
Mac this is fixed per putterman's comments on 12-15-1999 15:39.  
1. Sorted by Date and Thread, top level msg is deleted, result: children move to 
top level (not threaded anymore, and they appear in list by their date sort, 
which can separate them per their date), and next child is selected.
2. Sorted by Subject and Thread, top level msg is deleted, result: children move 
to top level (not threaded anymore, and they appear in the list by their subject 
sort, which keeps them in the same location), and next child is selected).

Verifying this, if  the above scenarios are not what you expected scott, please 
reopen and I will try again.  As mentioned by scott, there are other problems 
with deleting childern that are covered in other bugs.