Closed Bug 109985 Opened 23 years ago Closed 15 years ago

Wrong subject/sender/date in mail list window

Categories

(SeaMonkey :: MailNews: Message Display, defect)

defect
Not set
major

Tracking

(Not tracked)

RESOLVED WORKSFORME

People

(Reporter: oistrakh, Unassigned)

Details

Attachments

(1 file)

From Bugzilla Helper:
User-Agent: Mozilla/4.0 (compatible; MSIE 5.5; Windows NT 5.0)
BuildID:    2001101117

I've only gotten this problem once, and I couldn't reproduce it so I don't know 
what's relevant, but here goes:

I have mozilla connecting to a UW-IMAPD with SSL. I was connected to my INBOX. 
I had a message with attachments open, and I had the attachment open (excel 
file) and was reading it. I noticed that I had one new message in my INBOX, so 
I clicked to my INBOX, scrolled down to the bottom (I have messages sorted by 
date in ascending order) using the scrollwheel on my mouse, and clicked on the 
new message. The new message displayed fine in the preview window, and also 
displayed fine when I double-clicked on it to open it up. However, in the INBOX 
listing of all my messages, all the headers for that new message were 
incorrect. Mozilla displayed the sender, subject, and date of the previous 
message that I had been reading. When I responded to the new message, mozilla 
picked up the wrong sender/subject line in the reply message.

For example:

First message: sender-John, subject-hello, date-11/13/2001
New message: sender-Dave, subject-bye, date-11/14/2001

If I read the new message, the sender/subject/date in the message is 
Dave/bye/11/14/2001, which is correct. But in the INBOX list it displays it as 
John/hello/11/13/2001. If I respond to the new message, it tries to respond to 
John with a subject of hello, but it should respond to Dave with a subject of 
bye.

Again, I can't reproduce this right now. Closing and re-opening Mozilla does 
not get rid of this problem. It's possible that this is a bug in IMAPd, but 
nobody else (using Outlook Express and Navigator 4.x) has encountered this 
problem, so I figured I'd list it here and see if anyone can reproduce it.

Reproducible: Couldn't Reproduce

Actual Results:  Wrong headers displayed in the folder list, and wrong headers 
when responding to the message.

Expected Results:  Right headers displayed in the folder list, and right 
headers when responding to the message.
been seeing similar horkage on linux lately. Possible dup of bug 109605
I have this problem regularly. I am running Linux (Redhat 6.2), and reading mail
using IMAP over secure SSH port redirection. The subject/sender/dates of my
emails get garbled once every few days.

It seems to happen when a new mail arrives just as I am selecting a different
mail to read from the subject pane. The new mail is then permanently labelled
with the incorrect subject/sender/date of the existing email I selected as
described above. Interestingly the size field is correctly stated, and this is
the only means for me to tell the emails apart.

Once this has happened, it does not right itself. So I still have many emails in
my InBox with completely the wrong subject/sender/date displayed in the subject
pane. The only way I have found to correct it is to move the email into another
folder, at which point it assumes the correct details in the subject pane.

It would be nice to get a fix.
Marking new based on confirmation however this might just be corrupted header files.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Keywords: dataloss
OS: Windows NT → All
Hardware: PC → All
I just experienced a similar bug while sending myself a test messgae from a
Palm. That message is displayed in the list with an apparent time of precisely 2
monthes before real date.

Situation:
Mozilla 1.0 rc1 EN on Windows 2000 Pro Fr
Courier IMAP 1.3.8.2 on FreeBSD 4.5
The software used to send the mail from the Palm is Multimail SE 1.02

It seems I can reproduce it at will.
It persisted after a move to another folder and back.
It doesn't happen with Outlook XP.

So it would look like a mail header problem, generated by some MUAs.

Raphael Marmier

Annexe: one of the faulty mail:

From - Tue May 07 17:16:47 2002
X-Mozilla-Status: 0001
X-Mozilla-Status2: 00000000
Return-Path: <raphael@computer-rental.ch>
Delivered-To: raphael@computer-rental.ch
Received: (qmail 1422 invoked from network); 7 May 2002 07:27:17 -0000
Received: from unknown (HELO obelix.spectraweb.ch) (194.158.230.8)
  by 195.15.59.70 with SMTP; 7 May 2002 07:27:17 -0000
Received: from COM (pop-ls-8-1-1-dialup-133.freesurf.ch [194.230.230.133])
	by obelix.spectraweb.ch (8.11.2/8.9.3/SuSE Linux 8.9.3-0.1) with SMTP id g477Q6l03788
	for <raphael@computer-rental.ch>; Tue, 7 May 2002 09:26:07 +0200
Message-Id: <200205070726.g477Q6l03788@obelix.spectraweb.ch>
To: raphael@computer-rental.ch
Subject: test palm
From: "Raphaël Marmier" <raphael@computer-rental.ch>
Date: mar,  7 mai 2002 9:26
Mime-Version: 1.0
X-Mailer: MultiMail SE 1.0.0, Palm, Inc.
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 8bit

Ceci est un test avec du text.
I have had this happen to 3 out of 6 test users of the 1.0.0RC1 on RH 7.1 full
updates and imap. They can resend the message with incorrect subject to
themselves and the subject will then appear correctly.
Sounds like bug 107466
Tried to experiment a bit more.
I got confusing results to say the least, but maybe the problem has to do with
character encoding and charset stuff. I however lack the knowledge and the tools
to really experiment in that area.

Anyway, the problem is still here with rc2

best regards, Raphael
For a way to replicate this issue check out the (???same???) bug noted at:
http://bugzilla.mozilla.org/show_bug.cgi?id=107466
I have a sender/subject/date that is wrong in the message pane, but shows up
correctly in the mail view pane or on double clicking to open in a new menu.
The sender/subject/date is identical to the message which immediately followed
it (with pdf attachments; the 'wrong' message correctly notes it has no
attachments)when it was first received (using Thread sort) but it stays the same
even when moved to a different place (eg. sort by order received). If I forward
or 'edit as new' it, it works fine, but if I reply, it gets the correct address
to reply to, but but the subject is wrong (re: wrong subject...) and the text
saying xxx-wrote: is wrong.

If I access my mail directly (telnet, and using Pine) the correct subject, etc
is there.
I have seen this problem several times.  I am also using IMAP.
A new message shows up in my inbox with the same Subject and Sender as a
previous message.   Viewing the messsage body shows the correct message, but the
message index always shows the wrong data.

If I open my Inbox with another e-mail package, such as Eudora, the correct
message index is shown in Eudora.
I see this happen a lot too.  It seems to be an interaction between IMAP and
reading mail with an external mailreader.  I see it on my inbox, but here's a
reproducible test case using filters and mailboxes (Mozilla build 2002111108.)

1. Create a new filter to move incoming messages containing a particular subject
string to a new test mailbox.
2. From the server, send yourself two test messages that match the filter but
have distinct subject lines and contents (so you'll be able to tell them apart.)
3. Open the test mailbox in Mozilla.
4. Hit "Get Msgs" in Mozilla to fetch the messages.  See the messages appear in
the test mailbox.
5. Quit Mozilla completely (including browser windows) so it closes its
connection to the IMAP server.
6. On the server, using pine or mutt or whatever, delete the first of the two
messages and save the mailbox.
7. Restart Mozilla and open the test mailbox.

Now, on my system at this point, the header pane shows both of the original
messages.  If I click on the first one, the *second* one disappears from the
list, but its contents and subject are displayed in the message pane even though
the header pane shows the subject line of the first message (the one you deleted
on the server).  I'm now stuck with the bogus subject, no way to fix it short of
hunting down index file for that mailbox and deleting it.

It's worth noting that this test case doesn't work on my inbox; the first
message is correctly removed there, leaving the second one behind.  So maybe
there's an interaction with filters here, too.  But I *do* see the same problem
on my inbox pretty frequently.
One other note about this, a proposed sort-of-fix, since I realize it may not be
trivial to automatically detect changes to a mailbox.  The code should check to
make sure its cached information about a message matches the actual contents of
the message from the server, and update the cache if there's a mismatch.  When I
encounter this bug, the correct information does appear in the message pane, so
it ought to just be a matter of updating the header pane and the underlying
index file.  That way I'd at least be able to clear things up by reading each of
the misidentified messages once, which would make this bug much less annoying. 
Even if the underlying bug is fixed, this kind of self-healing is probably a
good idea since there could be other situations where the cache gets out of date
for whatever reason.
By the definitions on <http://bugzilla.mozilla.org/bug_status.html#severity> and
<http://bugzilla.mozilla.org/enter_bug.cgi?format=guided>, crashing and dataloss
bugs are of critical or possibly higher severity.  Only changing open bugs to
minimize unnecessary spam.  Keywords to trigger this would be crash, topcrash,
topcrash+, zt4newcrash, dataloss.
Severity: normal → critical
i'm also getting this on windows98se using pop3
Product: Browser → Seamonkey
Assignee: sspitzer → mail
Assignee: mail → nobody
QA Contact: esther → message-display
Shane, do you still see this problem with SM 1.1 or alpha 2?
  http://www.seamonkey-project.org/releases/2.0a2
Whiteboard: closeme 2009-02-01
=> WFM
Severity: critical → major
Status: NEW → RESOLVED
Closed: 15 years ago
Keywords: dataloss
Resolution: --- → WORKSFORME
Whiteboard: closeme 2009-02-01
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: