Closed Bug 21469 Opened 20 years ago Closed 20 years ago
Deleting messages in thread view "hides" thread children
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.
This is not PDT+. I can use mail just fine without this being fixed.
can I remove [DOGFOOD] then, waterson?
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.
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.
Putting on PDT+ radar.
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.
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.
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.
Whiteboard: [PDT+] → [PDT+] ETA Some time the beginning of January.
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.
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.
Whiteboard: [PDT+] ETA Some time in January. → [PDT-] ETA Some time in January.
Changing to pdt- per today's mtg and ok from phil.
need 23204. marking M14.
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 :-(
Whiteboard: [PDT-] ETA Some time in January. → ETA Some time in January.
Moving [DOGFOOD] to keyword field as dogfood.
Summary: [DOGFOOD] deleting messages in thread view "hides" thread children → Deleting messages in thread view "hides" thread children
Putting on PDT+ radar for beta1.
Whiteboard: ETA Some time in January. → [PDT+]ETA Some time in January.
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.
Whiteboard: [PDT+]ETA Some time in January. → [PDT+]2/11 + 1/2 a day per daily build regression + 1/2 a day per tree closure due to redness + 1/60th of a day for activities like this
Whiteboard: [PDT+]2/11 + 1/2 a day per daily build regression + 1/2 a day per tree closure due to redness + 1/60th of a day for activities like this → [PDT+]2/11
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.
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.
Status: ASSIGNED → RESOLVED
Closed: 20 years ago
Resolution: --- → FIXED
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.
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.