If you are reading a thread and it is open and you delete the first message in the thread the entire thread collapses. The desired behaviour should be that the thread should stay open if it started as open.
I see that happens too in the following builds. Linux (2000-04-18-08 M16) Win32 (2000-04-18-09 M16) Mac (2000-04-18-08 M16) Confirm this bug as NEW
Status: UNCONFIRMED → NEW
Ever confirmed: true
moving to M18 and nominating for beta3
Target Milestone: M17 → M18
This drives me crazy. I'm going to look at it. It's also a major performance problem (for threaded view users, anyway) because it causes a lot of extra stuff to happen.
Assignee: putterman → bienvenu
Status: NEW → ASSIGNED
On the other hand, if the thread is collapsed and you delete the first message, the thread expands, and then collapses. Sometimes, the resulting collapsed thread has no twisty by it so you can't expand it.
Scott and I figured out why the thread expands - it's a bug in our code that finds the next message to load and thinks it's doing a navigation. Fixing it is hard, however, because the code works with dom nodes, and unless you expand the thread, we can't find the next message to load.
Could you add a back-door method in the message folder or something that says, "get me the next thread child"?
Or, equally skanky, just use the "raw" RDF APIs to grovel the next kid?
we could add a method to find out the next message to load in the thread from the DB, as long as messages within threads aren't sorted by rdf - I heard that they were at one point (e.g., all second level headers are sorted by whatever the current sort is - is that true, Scott?). Anyway, the problem I was describing about having to expand the thread was just because that's the way the mailnews js code works - it could be changed to deal with URI's instead of dom nodes. Once the dust has settled, and the message has been promoted to the top level, and is in the dom, we can find it by URI (right, Scott?)
If the folder is closed, nobody will know that you pulled up "the wrong message" ;-)
we do use the raw rdf interfaces to get the next kid in this case. The problem is that when written the function returned a dom node and the only way to get a dom node was to expand the tree. Expanding the tree worked in every case I tested when I wrote the code, but I never tested this case and hence the bug. I'll just change this to return a uri instead of a dom node and let the calling code do the correct thing.
reassign to Scott, since this will require a bit of work.
Assignee: bienvenu → putterman
Status: ASSIGNED → NEW
Mail triage marking [nsbeta3+] reassigning to dimator.
Assignee: putterman → dimator
second pass: - per mail triage
Whiteboard: [nsbeta3+] → [nsbeta3-][cut 8/28]
Dimi Shahbaz's email address is invalid. reassigning to default component owner.
Assignee: dimator → putterman
QA Contact: fenella → esther
sorry for the extra email. Removing mail2 keyword.
reassinging to sspitzer
Assignee: putterman → sspitzer
QA Contact: esther → stephend
moving to mozilla0.8. marking nsbeta1+
*** This bug has been marked as a duplicate of 19412 ***
Status: NEW → RESOLVED
Last Resolved: 19 years ago
Resolution: --- → DUPLICATE
VERIFIED DUP of 19412
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.