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! :-)
mcafee - it's great to see you using mail :-)
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
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.
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.
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]
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.
- per mail triage
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.
Whiteboard: [nsbeta3-][nsbeta2-] → [nsbeta3-][nsbeta2-] relnote-user
reassigning to sspitzer and nominating mail3
Assignee: putterman → sspitzer
Status: ASSIGNED → NEW
marking nsbeta1+ and moving to mozilla0.9 milestone.
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.
bringing back into nsbeta1+. This should go away with the perfbranch landing.
Is this fixed now that the perf branch landed?
yes, this is fixed now.
Status: NEW → RESOLVED
Closed: 19 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
You need to log in before you can comment on or make changes to this bug.