Closed Bug 287271 Opened 19 years ago Closed 7 years ago

Text "Re: " in subject does not display in Thread pane

Categories

(MailNews Core :: Backend, defect)

1.0 Branch
defect
Not set
normal

Tracking

(Not tracked)

RESOLVED WORKSFORME

People

(Reporter: williamsca, Unassigned)

References

Details

(Keywords: regression, testcase)

Attachments

(2 files)

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8b2) Gecko/20050321
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8b2) Gecko/20050321

After receiving a message via IMAP in my inbox, I file that message into an IMAP
folder located on the server.  When I later select that folder, the "Re: " is
not shown in the upper pane when the message is a reply to a previous message. 
In the lower pane, the "Re: " is present.

I don't know exactly when this started, but it is sometime in the last several
weeks with the nightly builds.

I will attach a screen shot showing the problem.

Reproducible: Always
Confirming based on screenshot.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Keywords: regression
Summary: Text "Re: " does not display in upper pane in subject on replies → Text "Re: " in subject does not display in Thread pane
I don't see this problem at all. We reconstruct the Re: flag when parsing
headers, and in the test case, we'd reparse headers and set the Re: flag.
Assignee: sspitzer → mail
Here's a message that exhibits the problem in my mail client (Thunderbird 1.5 branch RC).  When I received this message into my IMAP Account->Inbox folder from the NetworkManager-list@gnome.org mailing list, a filter moved it to my IMAP->Misc folder, where the thread pane displayed its subject as "WPA status".

I then manually copied it back to IMAP->Inbox, where the thread pane also displayed it as "WPA status".  Then I copied it to Local Folders->Inbox, where the thread pane displayed it as "Re: WPA status".

Copying/moving it to various other folders had mixed results.  For example, when I copied it from Local Folders->Inbox to IMAP->Misc, it appeared in IMAP->Misc as "Re: WPA status".  But when I copied it from Local Folders->Inbox to IMAP->Inbox, it showed up there as "WPA status".
Moving this to the "Core" product per bienvenu's instructions for what to do when a bug appears in both products and it's unclear whether it's a frontend or backend bug.
Component: MailNews: Main Mail Window → MailNews: Backend
Product: Mozilla Application Suite → Core
Version: unspecified → Trunk
Assignee: mail → nobody
taking
Assignee: nobody → bienvenu
Version: Trunk → 1.0 Branch
I saved the .eml file as a local folder. The first time I opened it, I saw the bug. I then deleted the local folder and saved the .eml file again, and this time I didn't see the bug! So it seems to be random, somehow, or I'm confused.
This seems to occur when the header "thread-topic" is present in the mail message.  I.e., if that header exists, its value is displayed rather than the value of the "subject" header.  

I've watched my message display pane *change* from the proper subject line under "Subject" to the un-adorned value in thread-topic -- flipping down like an updating railway station train schedule.

The net result is that all messages in a thread look like they are first messages.

(I'm using Thunderbird 1.5 on MacOSX 10.4).
do any of you have extensions installed that might be affecting this?
Bug 311164 and bug 317355 appear to be this same problem; both report the problem on IMAP, as this bug does.

Bug 317355 comment 3 suggests the problem may be related to an all-upper-case "RE:" in the actual message source (which is displayed as "Re:" I guess).
No, I certainly don't.  I have only "talkback" and an old calendar extension
(which is disabled, because it's not compatible with this version of thunderbird).

(In reply to comment #9)
> do any of you have extensions installed that might be affecting this?
> 
No extensions for me either, and I must admit that I haven't seen this particular problem for quite some time, but I did do some testing around Bug 317355 comment 3 that you mentioned.

I sent myself a test message and then replied to that test message, changing the Re: to RE: in the compose window before sending.  When I received that email, the thread pane showed "Re: test" and when I selected the message for display in the lower pane, the subject line showed "RE: test", so it definitely appears as though Seamonkey is not displaying exactly what is in the header in the thread pane.
So -- in my experience, it may depend on the sending mail
client.  I don't have hard data (sorry), but I note that this happens with
most messages that I get at work (where many people use Outlook)
and rarely in public e-mail discussions (e.g., IETF mailing lists) where
people are using... not Outlook.

And, also note that I've seen it strip more than just "Re", but also
"Fwd" and so on.


(In reply to comment #12)
> No extensions for me either, and I must admit that I haven't seen this
> particular problem for quite some time, but I did do some testing around Bug
> 317355 comment 3 that you mentioned.
> 
> I sent myself a test message and then replied to that test message, changing
> the Re: to RE: in the compose window before sending.  When I received that
> email, the thread pane showed "Re: test" and when I selected the message for
> display in the lower pane, the subject line showed "RE: test", so it definitely
> appears as though Seamonkey is not displaying exactly what is in the header in
> the thread pane.
> 
It's independent from the sending mail client.

I can allways reproduce this with the following steps:

1. compose a test message with a subject beginning with "Re: "
   and save it in your drafts folder.
2. move message from drafts folder to another folder (Trash)
3. select the another folder from step 2. You'll see the message with
   the not truncated subject line.
4. select another folder like your inbox folder.
5. select the folder with your test message.
   the subject is missing the "Re: "

This happens with subjects beginning with "RE:" oder "Re:"
I can't reproduce this with tunderbird-1.0.x.
*** Bug 311164 has been marked as a duplicate of this bug. ***
still see this problem?
Assignee: bienvenu → nobody
Keywords: testcase
OS: Windows XP → All
QA Contact: backend
Hardware: PC → All
Yes!

I've found a workaround, after moving the message to another folder,
open the message in a new window.
Product: Core → MailNews Core
This problem still exists (again) in TB 3.0 beta2! This is a regression to TB3.0 beta1. With beta1 I cannot trigger this bug anymore!
I checked the nightly build since TB3.0 beta1.
The last nightly build which does not show this bug is:
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1b3pre) Gecko/20090205 Shredder/3.0b2pre

the next nightly build 
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1b3pre) Gecko/20090206 Shredder/3.0b2pre
has the described problem.
this feels like an uninitialized variable issue - those steps to reproduce don't cause the problem with my debug build. I'll try a release build next.
The patch from bug 359339
https://bug359339.bugzilla.mozilla.org/attachment.cgi?id=360576
seems the most likely culprit in that range. It's touching nsImapMailFolder::CopyMessages() and adding nsImapMailFolder::SetPendingAttributes().
bienvenu, can you take a look?
I'm skeptical that change caused this bug, since the code involved shouldn't be run for mail filters, plus the original steps to reproduce don't involve moving a message at all...I'm still trying to reproduce this, w/o any luck. Can you still reproduce this, Ben?
er, I guess those steps do involve moving a message, but not filters...I've tried those steps with a pre b3 release build, and they work fine.
Yes, I'm still seeing the bug in the old 20081217 build that I'm using, but I haven't found a reliable way to trigger the bug or conditions which are related.
Some things I observe, factors that seem to be influencing the bug:
* New mail: new mail (received a few minutes ago) may show the bug, while older (received yesterday, before I restarted TB) doesn't.
* Opening the folder: it matters whether the folder had been opened when new mail arrives. Selecting another folder and going back to the previous folder sometimes changes matters, i.e. makes the "Re:" appear correctly, sometimes not.
Maybe depending on the max. 4 IMAP connections we make? I.e. when the folder is re-opened with a new IMAP connection, it's displayed correctly?
* Restarting TB matters: After a restart, display is usually correct. New mail then is again wrong, even in the same thread.

Another anecdotal evidence: I just fetched mail from one week, including a long email thread (including the thread starter). I used threaded mode for this particular folder (unthreaded for all others). All msgs had the "Re:", including the thread starter. When I opened the thread starter, the "Re:" in the thread pane disappeared. This is unusual: IIRC, opening a msg usually didn't "fix" the "Re:" display in the thread pane. Maybe that's because I usually use unthreaded mode, as said.
Ben, your symptoms seem to be consistent with the view flags array not getting updated correctly when new headers are added to the view. When displaying message subjects in the thread pane, we use the flags from the view's m_flags array to determine if we need to stick Re: in front of the subject. If switching folders fixes the view, that means that the db hdr has the right flags, but the m_flags value for the row was wrong before.

All that being said, this all WFM...but it might be interesting to see if that info helps you recognize some sort of pattern.
(In reply to Markus Kurek from comment #14)
> It's independent from the sending mail client.
> 
> I can allways reproduce this with the following steps:
> 
> 1. compose a test message with a subject beginning with "Re: "
>    and save it in your drafts folder.
> 2. move message from drafts folder to another folder (Trash)
> 3. select the another folder from step 2. You'll see the message with
>    the not truncated subject line.
> 4. select another folder like your inbox folder.
> 5. select the folder with your test message.
>    the subject is missing the "Re: "
> 
> This happens with subjects beginning with "RE:" oder "Re:"
> I can't reproduce this with tunderbird-1.0.x.

I cannot repro with the testcase or these steps. As there has been some vagueness, I won't close, but please retest, everyone.

Thunderbird 52.1.1 (32-bit)
Windows 7 64-bit
I haven't seen the bug in years.
WORKSFORME (now, even though I saw the bug before, according to the comments above)
Status: NEW → RESOLVED
Closed: 7 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: