273497 - messages with the same subject are groupped in one thread

Status: RESOLVED WORKSFORME

(Thunderbird :: Mail Window Front End, defect)

Description

[Vladimir Kondratyev]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.5) Gecko/20041107 Firefox/1.0
Build Identifier: Thinderbird version 1.0RC1 (20041201)

I'm using threaded mode. All messages are sorter by "order received" descending.
All messages with the same subject are groupped in the one thread. It's wrong.
This is absolutely different messages.

Reproducible: Always
Steps to Reproduce:
1. Switch to "threaded" mode + sort messages by "order received"
1. Write 3 e-mails with subject "a"
2. Download these e-mails
3.

Actual Results:  
All messages with subject "a" are groupped by single thread

Expected Results:  
It should not be.

Comment 1

[dolphinling]

Dupe of bug 164115 (or bug 231764)

Comment 2

[David :Bienvenu]

set the hidden pref "mail.thread_without_re" to false in your prefs.js

Comment 3

[Clint Olsen]

(In reply to comment #2)
> set the hidden pref "mail.thread_without_re" to false in your prefs.js

I attempted to set this in Thunderbird 1.0, but this does not help.  Yes, I've
deleted my .msf files, and it still threads unrelated messages together by
subject.  It's really difficult sifting through all these reports when Mozilla
and Netscape bugs are intertwined with Thunderbird reports.  Since they are
different tools, it would be helpful if these bugs did NOT reference each other.
 It's next to impossible to tell which tool actually has the fix and which does not.

Comment 4

[David :Bienvenu]

this pref is implemented in backend code shared between all three apps. The pref
works as designed, according to many people who've used it. So either you've not
edited your prefs.js file successfully, or you've deleted the wrong .msf files,
or it's not designed to do what you want. What the pref does is make it so we
don't combine messages with the same subject in one thread, in the case that
none of the messages start with Re:.

Comment 5

[Clint Olsen]

(In reply to comment #4)
> What the pref does is make it so we don't combine messages with the same
> subject in one thread, in the case that none of the messages start with Re:.

I replied to you in private, but apparently that won't get catalogued correctly.
 I added it to user.js, which then incorporated the switch into prefs.js the
next time Thunderbird wrote out this file.

I deleted all my .msf files just to eliminate that as a potential source of the
problem.

I think I understand how/why the two messages in question got threaded.  They
both started with an 'Re:' even though they were unrelated messages.  I have
caution you that if this is the way this feature is supposed to work, this
heuristic is NOT reliable.  You need to use the References: headers to get
threading correct.

The Mutt developers already went through this turmoil quite some time ago. 
Subjects lines are just too unpredictable to expect that they won't collide in
some way.  Besdies, 'Re:' is language/mailer dependent.  Not every mailer uses
the same prefix string when replying to messages.  In some, they might use
"Aw:", and there are others.  You also can't necessarily expect it's a prefix
either.  It was common that some mailers used "Fwd: [ <original subject> ]" when
forwarding messages.  You can imagine this nesting in hideous ways.

Comment 6

[David :Bienvenu]

If every mailer generated reference headers, then you'd be right. But even such
mainstream mailers as Microsoft Outlook don't always do it. Not to mention
web-mail...

Comment 7

[Clint Olsen]

Well, in that case, you have to ask yourself which is more important?  Is it
better to be correct and miss a some threading opportunities with Doubtlook
morons or to be broken and overthread things?

Or better yet, why not let the user decide:

user_prefs("mail.thread_by_subject", false);

Or see:

http://www.mutt.org/doc/manual/manual-6.html#strict_threads

Comment 8

[David :Bienvenu]

asked and answered, years and years ago...believe me, you're not the first
person to bring this up. We tried turning it off by default, and there was such
a wailing and gnashing of teeth that I don't think we'll ever turn it off by
default again.

Comment 9

[Vladimir Kondratyev]

I think that Thunderbird is _absolutely_ unusable with current threading
behavior. I've tried to edit prefs.js and it doesn't help. So I've immediately
threw away this _annoying_ mail client. I'm working at technical support
department and we have _a lot_ of mails with the same subject and Thunderbird
makes a total mess from e-mails. "WORKSFORME" status is just a joke. It doesn't
work for me - absolutely ordinal user who wants _normal_ threading without
tweaking internal geek's files.

Comment 10

[Magnus Melin [:mkmelin]]

FWIW, bug 277190 implemented a strict threading pref. (The pref in comment 7 does not exist.)

Comment 11

[Åsmund Skjæveland]

It's a wee bit inconvenient that you have to dive into your .thunderbird folder and delete all *.msf files to make mail.thread_without_re=false and mail.strict_threading=true retroactive, particularly for the likes of me who store their mails in ~100 sorted mailboxes. Wouldn't it make sense to at least have a 'flush mail header cache' button or suchlike somewhere?

Comment 12

[David :Bienvenu]

TB 2.0 has a button on the folder properties dialog, but it only does a single folder. That would really be a power user thing, and might make a good extension.

Comment 13

[garth]

It seems a bit silly to have to re-create accounts all the time just to make threads unread. I'd like to back up a profile one day and include a "snapshot" of all my email messages and newsgroup threads, so while I'm thinking of this can someone design a backup mechanisim for the Profile Manager that performs backup for TB3?

Comment 14

[Jason King]

A feature I fell in love with in mutt or mutt-ng was the ability to break up a bunch of messages that mutt had decided (because of either subject or message id) were in the same thread.

You just tagged them and hit (I think) # and it would break the threading for just those messages (and remember that it was broken).  That feature could only have been improved upon if there was a simple way to provide a regex for subject (or even senders) which would let the client know never to group based on that subject (or for those senders).

So then the threading is done basically on message id, and all subjects that don't match the exclusion list.  Plus some way of manually breaking a message out of a thread, although the need for that would be rare if the subject exclusion regex thing was implemented.

Comment 15

[Frank Thieme]

Just a suggestion: would be nice if TB don't make a thread of all mails aver received with this Subject. Maybe some (eventually self configurable) time limit within a message is put to the same thread.

I'm actually send some birthday invitations and get mails of the year 1998 in the same thread. Very annoying this...