362123 - Strange bugs with specific email thread

Status: RESOLVED WORKSFORME

(Thunderbird :: Mail Window Front End, defect)

Description

[Phillip Susi]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1) Gecko/20061010 Firefox/2.0
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1) Gecko/20061010 Firefox/2.0

I am running Thunderbird 1.5.0.8 and came across a thread on a public mailing list ( ubuntu-dev ) that caused thunderbird to behave strangely.  The folder showed 2 unread messages, but when I opened the folder, thunderbird showed this thread but it had no unread messages listed in it.  I usually operate in the show threads with unread messages mode.  If I change to show unthreaded unread messages, the two new messages showed up, but changing back to show threads with unread mode caused the two new messages in the thread to be hidden again ( though the thread itself was still shown ).  

I normally use an IMAP server for my mail, so to debug this issue I copied the offending thread to a local mbox folder.  This time when viewing the mailbox in show threads with unread mode, the thread shows up, and if I click the + icon to expand the tree, the two new messages also show up, HOWEVER, if I click the - icon to collapse the tree, the whole thread immediately vanishes.  If I switch to another folder then back to the test folder, the thread shows up again and I can once again expand the view to see the new messages, then collapse it and the thread vanishes.  



Reproducible: Always

Comment 1

[Phillip Susi]

Attachment: Mbox with problem thread

This mbox file contains the troubled thread with the two new messages still marked as unread.  Open the mailbox in show-threads-with-unread mode and expand then contract the thread tree and the whole thing will vanish even though it still contains the two unread messages.  

Try copying the thread to an IMAP folder and see if the two new messages show up at all when in show-threads-with-unread mode.

Comment 2

[Mike Cowperthwaite]

(In reply to comment #0)
> to debug this issue I copied the offending thread to a local mbox folder. 
> This time when viewing the mailbox in
> show threads with unread mode, the thread shows up, and if I click the + icon
> to expand the tree, the two new messages also show up, HOWEVER, if I click the
> - icon to collapse the tree, the whole thread immediately vanishes.

I wasn't able to reproduce this under Windows with 1.5.0.8 nor 2b1-1122.  I'll try this under Linux later.

In your IMAP account, you could try deleting the .MSF file and let it rebuild, that might fix the display problem there.  This kind of problem is so common, 2.0 adds a Rebuild Index button for the folder's Properties.

Comment 3

[Phillip Susi]

I tried deleting the msf with no help.  They really need to get rid of that borked "Mork" index format.  

So opening that mbox and clicking the + then - on the thread tree ( you have to view it in threads with unread mode ) doesn't make it vanish for you?  It opens and closes properly and shows the two unread messages?

Comment 4

[Magnus Melin [:mkmelin]]

I can confirm that, using todays 1.5.0.8 security nightly build, but not with todays 2.0 pre beta build.

Delete the .msf for the testcase, restart, make the view threaded and click the minus sign - the thread doesn't show anymore - at all. It comes back if you click sort by e.g. sender though.

But, the bad part here: Once you get in to the threaded mode, one of the mails doesn't show anymore. And clicking elsewhere won't make it show.

From the testcase, it's the mail with Date: Mon, 27 Nov 2006 06:54:31 -0500 that doesn't show. Haven't figured out why, but before threading you have 11 mails, after you only see 10.

Maybe bug 360409 isn't completely fixed on the sec branch... 

Comment 5

[David :Bienvenu]

this problem has nothing to do with mork - mork is just storing and retrieving the data it's told to store and retrieve.

sounds like this is fixed in 2.0, unless I'm not quite following the comments.

Comment 6

[Daniel Veditz [:dveditz]]

Not blocking the old security branch, not a security bug and users will be able to upgrade to get the fix.  If someone figures out a simple (e.g. low-risk) diff that fixes this we can look at approving the patch.

Comment 7

[Phillip Susi]

(In reply to comment #5)
> this problem has nothing to do with mork - mork is just storing and retrieving
> the data it's told to store and retrieve.
> 
> sounds like this is fixed in 2.0, unless I'm not quite following the comments.
> 

Yea, but mork sucks as a file format.  One of my msf files is 51 megs of impossible to parse text, and from what I have heard, the code to manipulate it is impossible to maintain.  Index files should be memory mapped binary data structures for compactness and speed, not double indirect keyed text files.  

Comment 8

[Magnus Melin [:mkmelin]]

Attachment: simplified testcase

This is a simplified testcase (from the one above) with only three messages. As follows
 mail A references C, B and others
 mail B in-reply-to C, references C
 mail C

Mail A disappears.

Comment 9

[Magnus Melin [:mkmelin]]

This is not a recent regression, at least tb 1.5.0.5 has it. 

I'd reconsider the blocking though... this is dataloss, and upgrading to 2.0 does not make the message show up in the folder.

Comment 10

[Phillip Susi]

(In reply to comment #9)
> This is not a recent regression, at least tb 1.5.0.5 has it. 
> 
> I'd reconsider the blocking though... this is dataloss, and upgrading to 2.0
> does not make the message show up in the folder.
> 

Well, it isn't exactly data loss, just data hiding.  The message is still there, you just can't see it unless you change viewing modes.  Still,  should be fixed ;)

Comment 11

[Magnus Melin [:mkmelin]]

The important part seems to be that mail A references B, C and some mail that we don't have. 

You can change cut it down to (for mail A):
References: <[e-mail]>
 <[e-mail]>
 <[e-mail]>

Comment 12

[Phillip Susi]

What is the references: header even supposed to do anyhow?  The thread tree is based on the Reply-to: headers, so what is References: for?

Comment 13

[David :Bienvenu]

I think you mean in-reply-to, and we use references instead of in-reply-to, if it's present. References gives you the full list of references...

Comment 14

[Phillip Susi]

You mean references: allows the message to appear as a child of several parents?  Unlike In-reply-to:, of which, there can be only one?

How do you send messages that reference multiple other messages?

Comment 15

[David :Bienvenu]

not multiple parents, multiple ancestors. So if you have the following

A
  B
    C

where C is a reply to B, which is in turn a reply to A, C has two references. If you delete B, we'd still like to show that C is a descendant of A, so we use the references header.

Comment 16

[Wayne Mery (:wsmwk)]

Can someone replace the title with something more descriptive?  I'd do so but I'm sure to muck it up.

this isn't a dupe?  it sounds vaguely familiar to me.

Comment 17

[Wayne Mery (:wsmwk)]

Phillip, have you checked whether this problem is previously reported?

Comment 18

[Magnus Melin [:mkmelin]]

->WFM. I don't see this on trunk, and from the comments it was 1.5 only

Comment 19

[Phillip Susi]

It appears to be working properly in 2.0.0.9.