Closed Bug 19412 Opened 24 years ago Closed 23 years ago

Deleting top thread message shifts rest of thread


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



(Not tracked)



(Reporter: mcafee, Assigned: sspitzer)



(Whiteboard: relnote-user [nsbeta1+])

Deleting top thread message shifts rest of thread
to another part of your inbox, presumably it is re-sorting
according to the date of the new top thread.  4.5 didn't
do this, and this appears like you're ! deleting the
entire thread (until you find it later).
threads are great though, thank you scott! :-)
QA Contact: lchiang → esther
mcafee - it's great to see you using mail :-)
Target Milestone: M14
This is a tough one.  We've been debating how to resolve this.  The reason this
happens is that in 5.0, threads and sorting are independent of one another.  So,
if you are sorted by date and then delete a top level thread, the new top level
thread might have a date that causes it to get resorted.

There are two problems here.  The first is the resorting.  The second is that it
doesn't scroll to the right place and doesn't reselect.

This is a hard problem to solve.  The current goal is to not resort the message.
There's been debate on this (in the newsgroup as well).  If we choose to not
resort the message this could be a bit of work.  If we do, then there is no
Not holding B1 for this.
Target Milestone: M14 → M16
Priority: P3 → P2
we are going to solve this by going back to 4.x behavior where threads are a 
sort. This way I can make it so that threads are sorted in such a way that this 
doesn't occur.

marking nsbeta2.
Keywords: nsbeta2
Target Milestone: M16 → M17
Putting on [nsbeta2+][6/01] radar.  This work must be done by 06/01 or we may 
pull this for PR2.
Whiteboard: [nsbeta2+][6/01]
We decided to do what I said in my last comment.  Threading will become a sort 
again so that you cannot be in thread mode as well as be sorted by something 
Priority: P2 → P1
Due to slip in schedule, moving this bug from [6/01] to [Will be minus on 6/15] 
for fix deadline.
Whiteboard: [nsbeta2+][6/01] → [nsbeta2+][Will be minus on 6/15]
Priority: P1 → P2
Cleaning up status whiteboard by marking beta2 minus. (We're past 6/15)
Adding relnote and beta3 nomination.
The release note will warn/explain that messages groups are "sorted" based on 
the lead (parent?) message in the group.  If that parent message is deleted, 
then the distinct children groups each get "re-sorted" into the header list.
Keywords: nsbeta3, relnote
Whiteboard: [nsbeta2+][Will be minus on 6/15] → [nsbeta2-]
Changing jar's "relnote" keyword to "relnote2" 
Keywords: relnoterelnote2
Keywords: mail2
Whiteboard: [nsbeta2-] → [nsbeta3-][nsbeta2-]
- per mail triage
Target Milestone: M17 → Future
any movement on this?  This is on the top of my personal mail/news usability
bugs. :)
To answer blizzard's question, this got a minus in the review for fixing for
beta3 (and RTM).  It most likely will not be fixed for this release.
I second blizzard, we are not done here and ? I'd really
like to see something happen here before RTM.
I'll third blizzard and mcafee: I can't use mozilla in threaded mode with this
bug, and I rely on threading to read large lists/groups.  So I still need to use
4.x or some other mailer for news and for certain mailing lists.
*** Bug 55229 has been marked as a duplicate of this bug. ***
Are you able to delete messages in news that it prevents you from using it to
read news?
Oh, no, I guess not in news, so this only applies to mailing lists.  I was
probably thinking of the mozilla lists (which can be mail or news) when I wrote
sorry for the extra email. Removing mail2 keyword.
Keywords: mail2
Keywords: relnote3
Whiteboard: [nsbeta3-][nsbeta2-] → [nsbeta3-][nsbeta2-] relnote-user
reassigning to sspitzer and nominating mail3
Assignee: putterman → sspitzer
Keywords: mail3
QA Contact: esther → sheelar
marking nsbeta1+ and moving to mozilla0.9 milestone.
Keywords: nsbeta2, nsbeta3nsbeta1
Whiteboard: [nsbeta3-][nsbeta2-] relnote-user → relnote-user [nsbeta1+]
Target Milestone: Future → mozilla0.9
moving to mozilla0.8 milestone.
Target Milestone: mozilla0.9 → mozilla0.8
*** Bug 36118 has been marked as a duplicate of this bug. ***
moving to mozilla0.9
Target Milestone: mozilla0.8 → mozilla0.9
marking nsbeta1-. We are going to focus on thread pane performance rather than this.
Keywords: nsbeta1nsbeta1-
Whiteboard: relnote-user [nsbeta1+] → relnote-user [nsbeta1+ 1/28]
Target Milestone: mozilla0.9 → Future
bringing back into nsbeta1+.  This should go away with the perfbranch landing.
Keywords: nsbeta1-nsbeta1
Whiteboard: relnote-user [nsbeta1+ 1/28] → relnote-user [nsbeta1+]
Target Milestone: Future → mozilla0.9
Is this fixed now that the perf branch landed?
yes, this is fixed now.
Closed: 23 years ago
OS: Windows NT → All
Hardware: PC → All
Resolution: --- → FIXED
mac-2001-04-02-10 This problem is now fixed
Product: Browser → Seamonkey
You need to log in before you can comment on or make changes to this bug.