Closed Bug 19412 Opened 25 years ago Closed 24 years ago

Deleting top thread message shifts rest of thread

Categories

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

defect

Tracking

(Not tracked)

VERIFIED FIXED
mozilla0.9

People

(Reporter: mcafee, Assigned: sspitzer)

References

Details

(Whiteboard: relnote-user [nsbeta1+])

win32 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 :-)
Status: NEW → ASSIGNED
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 work.
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 else.
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 that.
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
Status: ASSIGNED → NEW
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.
Status: NEW → RESOLVED
Closed: 24 years ago
OS: Windows NT → All
Hardware: PC → All
Resolution: --- → FIXED
verified, win98-2001-04-02-06 linux-2001-04-02-08 mac-2001-04-02-10 This problem is now fixed
Status: RESOLVED → VERIFIED
Product: Browser → Seamonkey
You need to log in before you can comment on or make changes to this bug.