208324 - View|Threads|Unread + Threaded sometimes mixes up sub threads

Status: NEW

(MailNews Core :: Backend, defect)

Description

[Frank Schönheit]

When viewing unread messages only (View|Threads|Unread), in threaded display,
sometimes the messages in such a thread are completely mixed up (I'll attach a
mbox file and a screenshot showing this).

This makes reading in this view pretty difficult, because advancing
top-to-bottom in the view jumps forth and back between different sub threads.

Comment 1

[Frank Schönheit]

Attachment: mbox for reproducing the problem

The zipped mbox in this attachment allows to reproduce this. Simply extract it
to your "Local Folders" storage location, open it in MailNews, select
"View|Threads|Unread", and enable threaded display (by clicking onto the
respective icon in the message view header).

Comment 2

[Frank Schönheit]

Attachment: screenshot showing the result of the mbox file

this screenshot shows how badly the messages are mixed up. In Threads which
have say 50 or so messages, this makes following the thread properly really
difficult ...

Comment 3

[Frank Schönheit]

Attachment: suggested patch

Comment 4

[Frank Schönheit]

Comment on attachment 124934 [details] [diff] [review]
suggested patch

ducarroz, if you'd have some time for reviewing this ....

Basic idea for this patch is to apply the same code which is used to properly
display messages in "Threads|Threads With Unread" mode.
There, the view correctly uses an enumerator provided by the nsIMsgThread to
get the messages in this thread in-order.
I simply re-use this in ListUnreadIdsInThread, in case we're in threaded view
(m_viewFlags & kThreadedDisplay).

Drawback: We have O(n^2) now, instead of the former O(n): However, I think that
this is necessary for any fix to this problem ...

Additionally, there are now some small differences to the old behaviour, e.g.
that in m_flags, the flags as returned by the header, _excluding_
MSG_VIEW_FLAGS, are stored - which wasn't the case in the old code.
However, I believe that these small differences don't have real impact (or even
make things better :), but I may be wrong on this.

Comment 5

[Frank Schönheit]

Comment on attachment 124934 [details] [diff] [review]
suggested patch

obsoleting the patch

I'm going to write down "Never tamper with unknown code deep in the night!" 100
times ....

The patch does not work for threads where the deepest common ancestor of two
unread nodes is not unread itself.
E.g. (simplest case):
- (read)
  +- unread
  +- unread

Comment 6

[Arkady Belousov]

*** Bug 339561 has been marked as a duplicate of this bug. ***

Comment 7

[Arkady Belousov]

(In reply to comment #6)
> *** Bug 339561 has been marked as a duplicate of this bug. ***

Copy&paste for last comment from bug 339561:

> Depending on where in the thread the various messages have been marked
> unread, this problem may not be solveable.

     Probably. Though, I suggest, that inheriting childs of readed parent to
its grand-parent (without spreading/sorting grandsons across sons) should solve
this issue at once.

Comment 8

[Mike Cowperthwaite]

*** Bug 360350 has been marked as a duplicate of this bug. ***

Comment 9

[Mike Cowperthwaite]

Threading is a backend function. moving to Core.

Comment 10

[Kurt Pruenner]

Regarding the quote in comment #7:

> Depending on where in the thread the various messages have been marked 
> unread, this problem may not be solveable.

I'm pretty sure the same functionality was working fine for ages in Netscape 4.x, so I'm quite confident it's doable in TB as well...

np: Underworld - Dark & Long (DubNoBassWithMyHeadMan)

Comment 11

[Kurt Pruenner]

Sorry for the double post, but something just came to mind:

I don't really care for the lines drawn between the nodes of the message list, but I do care for proper sorting - so how about the possibility to choose "View > Threads > Threads with Unread" to get proper ordering and then just hiding all rows that are read when "View > Messages > Unread" is selected?

Sure, the lines will still look funny if they're drawn as if the lines in-between weren't hidden, but at least the order is correct, which I'd say is more important...

Comment 12

[Wayne Mery (:wsmwk)]

Is this gone for you?
I can't recall seeing sub threads mixed up in TB 2, SM 1.1.4 or trunk. 

Comment 13

[Frank Schönheit]

Hmm, I'm using Seamonkey 1.1 (don't recall the exact micro ATM, and cannot look it up right now). And yes, from time to time I have the exact same problem in the View/Threads/Unread view.

Comment 14

[Joshua Cranmer [:jcranmer]]

My various encounters with this bug imply to me that it may actually be a manifestation of an XUL bug/feature. I'll have to verify, though. Definitely, though, I've seen it other parts of View Threads, for example, when expiring news messages in threads.

Comment 15

[Arkady Belousov]

Attachment: bad threading redraw

I too see wrong threading redraw in different cases, not only when Unread is turned on. For example, send yourself some letter and twice answer for it. Result you may see in screen shot, which I attach.

Comment 16

[hansen]

I can't reproduce with latest nightly and test mbox (attachment 124932 [details]).

Couldn't this be an issue with compacting folders?
Does the problem occur if you run File > Compact Folders and restart Thunderbird?
It might require a rebuild of the index...

Comment 17

[Arkady Belousov]

Problem not with mailbox, problem with redrawing. If you close TB window by other window and then open TB window again, tree will be drawn correctly. Of course, Compact Folders doesn't help. Precise steps to reproduce:

1. Stay in inbox.
2. Create (^M) letter to yourself. F5 to receive it back from server.
3. Answer to received letter. F5 again.
4. Second time answer to first letter. F5 again.

Comment 18

[Arkady Belousov]

Attachment: more complex example of wrong drawing

More complex scenario. First, repeat steps from previous report. Then:

5. Answer to second letter. F5 to receive answer.
6. Answer to last (4th) letter. F5 to receive answer.
7. Remove (Del) 4th letter.

Now you may see, how tree for 5th letter is mixed. This bug will not by cured by closing  TB window by other window and then switching to TB back. But this redrawinf bug cured, if you switch from current folder to other folder and then open original folder again.

Comment 19

[Wayne Mery (:wsmwk)]

consider testing latest beta http://www.mozillamessaging.com/en-US/thunderbird/early_releases/ and report the results

Comment 20

[Wayne Mery (:wsmwk)]

(Arkady is not in a position to test)

Comment 21

[buovjaga]

(In reply to Arkady Belousov from comment #18)
> Created attachment 319111 [details]
> more complex example of wrong drawing
> 
> More complex scenario. First, repeat steps from previous report. Then:
> 
> 5. Answer to second letter. F5 to receive answer.
> 6. Answer to last (4th) letter. F5 to receive answer.
> 7. Remove (Del) 4th letter.
> 
> Now you may see, how tree for 5th letter is mixed. This bug will not by
> cured by closing  TB window by other window and then switching to TB back.
> But this redrawinf bug cured, if you switch from current folder to other
> folder and then open original folder again.

Still repro.

Thunderbird 45.8.0
Windows 7 64-bit

Comment 22

[buovjaga]

Still repro

TB 60.5.1 (64-bit)
Arch Linux

Comment 23

[Wayne Mery (:wsmwk)]

buovjaga, does this reproduce for you with version 115?

Comment 24

[buovjaga]

Yes, still repro like in my comment 21. The indentation of "test threading 5" is too big and this is cured by switching to another folder and back.

115.5.1 (64-bit)
Mozilla Thunderbird for Arch Linux