608719 - Message window shows additional recipients pulled out of nowhere

Status: RESOLVED INVALID

(Thunderbird :: Message Reader UI, defect)

Description

[Paolo Bonzini]

User-Agent:       Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.12) Gecko/20101027 Fedora/3.6.12-1.fc13 Firefox/3.6.12
Build Identifier: 

As visible in the attachment, the message window shows extra recipients that are not present in the original message.  Clicking Reply doesn't include these wrong recipients in the compose window.

This bug is causing me multiple heart attacks, because I see random unrelated public mailing lists included in the recipient list of confidential messages.

Reproducible: Sometimes

Steps to Reproduce:
1. Click randomly on messages
2.
3.
Actual Results:  
After a while, you'll see a message whose listed recipients makes no sense.

Expected Results:  
Listed recipients match message headers.

Happens roughly 1-2 every day to me.

Comment 1

[Paolo Bonzini]

Attachment: picture showing the source of a message and how it is shown in the message window

"Frank Ch. Eigler" is shown in the message window but is not in the headers.

Comment 2

[Paolo Bonzini]

Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.9) Gecko/20100921 Fedora/3.1.4-1.fc13 Lightning/1.0b3pre Thunderbird/3.1.4

Comment 3

[Ludovic Hirlimann [:Usul]]

does a right click on the folder -> properties -> rebuild index fixes the issue ?

Comment 4

[Paolo Bonzini]

I did it for one particular folder and it fixed it (in case it matters, I had to select folder A, do rebuild index on folder B while offline, restart thunderbird).  This was an NNTP folder by the way.  I then rebuilt indexes for all the other inboxes I have.  I'll see if it happens again.

Comment 5

[WADA:World Anti-bad-Duping Agency]

(In reply to comment #0)
> Steps to Reproduce:
> 1. Click randomly on messages

May be a variant of bug 533499.
Is "quickly" and "many times" involved in your "randomly"? 

> As visible in the attachment, the message window shows extra recipients that
> are not present in the original message.

What do you call by "message window"?
Message pane of three pane window? New or existent stand alone message display window? New or existent Tab? 

How about other fields such as Subject:, Date: at header box?
How about mail body display?
How about attachment pane display?
Always To: header related phenomenon only?
Is there other mail which has the To: header shown at the "message window"?
If yes, mail clicked just before the mail? Or mail which is irrelevant to you random click?

(In reply to comment #4)
> This was an NNTP folder by the way.

Do you use News server as your mail server?

> I did it for one particular folder and it fixed it.

Does it mean next?
In phenomenon of comment #0, wrong To: was shown again when you clicked other mail then clicked the mail again?
i.e. Wrong To: was always shown for the specific mail in comment #0 once problem happened, and rebuild index("Repair Folder" in Tb 3.1) was only available recovery procedure.

Comment 6

[Paolo Bonzini]

> Is "quickly" and "many times" involved in your "randomly"? 

No, not necessarily.

> What do you call by "message window"?
> Message pane of three pane window? New or existent stand alone message display
> window? New or existent Tab? 

Any of these.

> How about other fields such as Subject:, Date: at header box?
> How about mail body display?
> How about attachment pane display?
> Always To: header related phenomenon only?

All of these are correct.  Cc: can be incorrect too, I don't remember ever seeing an incorrect From: or Reply-To:.

> Is there other mail which has the To: header shown at the "message window"?

No, absolutely.  I even see addresses that should have never appeared in that account (i.e. they only sent email to other accounts I have).

> > This was an NNTP folder by the way.
> 
> Do you use News server as your mail server?

No, my mail servers are company and Google, this news server was Gmane.

> > I did it for one particular folder and it fixed it.
> 
> Does it mean next?
> In phenomenon of comment #0, wrong To: was shown again when you clicked other
> mail then clicked the mail again?
> i.e. Wrong To: was always shown for the specific mail in comment #0 once
> problem happened, and rebuild index("Repair Folder" in Tb 3.1) was only
> available recovery procedure.

Yes.  I'll report whether it fixed it also for mail folders I repaired, it will take a few days to know for sure.

Comment 7

[Paolo Bonzini]

The bug reproduced again, and "repair folder" didn't fix the visualization---only restarting Thunderbird did.  Since in comment #4 I was both repairing and restarting, it looks like repairing has no effect on this bug.

The extra recipient can be found in a thread I had been reading 10-15 minutes before.  I wasn't browsing particularly fast that thread, I believe.  In no case I've witnessed misplaced attachments, but this doesn't totally rule out that this is a dup of bug 533499.

Comment 8

[WADA:World Anti-bad-Duping Agency]

Paolo Bonzini(bug opener), show "Order Received" column. Column value is article number(unique ID of article) in a news group assigned by NNTP server if NNTP.
And, save article as .EML file when you see problem again, and keep back up of "...\News\A.B.C\x.y.z" file and "...\News\\A.B.C\x.y.z.file" file(where A.B.C is newsserver name and x.y.z is news group name), for further diagnosis by developers, and to see no problem in downloaded news article data or not, please.

(In reply to comment #7)
> The bug reproduced again, and "repair folder" didn't fix the
> visualization---only restarting Thunderbird did.

How about next?
  Open new Tb Window, via "Open" of context menu of account/folder,
  before/after "repair folder", instead of restarting Thunderbird,
  and view the article again at opened new Tb window.
Please check it when you encounter problem again.

Comment 9

[Paolo Bonzini]

I already did that, there is no problem in the .eml file.  I'll check the .msf file as soon as the problem reproduces again (though I suspect it will be okay, since restarting Thunderbird fixes the problem).

If I remember correctly, opening a new Thunderbird window or tab keeps the wrong recipients, but I'll double check that.

Comment 10

[Paolo Bonzini]

I'm now 100% sure that:

1) extraneous recipients can be pulled out of other accounts, i.e. there are no messages sent to those recipients in the current account;

2) it is not related to browsing particularly fast.  I was reading email slowly this morning when the bug reproduced;

3) when multiple recipients are added, they are usually related, for example they may all be recipients of a recently sent email (though the mail was sent from another account);

4) the .msf file does not include the wrong recipients;

Also, today, a message had two extraneous recipients, and opening it into a new tab with the message showed only one.  The other went away.  From that point on, the now absent recipient never showed up, but redoing the operation didn't kick out the remaining intruder.

Doing open repair folder + new tab didn't help.  As usual, however, restarting Thunderbird did.

If you want me to run with some kind of debug extension and grab more info the next time I reproduce the bug, I can do that of course.

Comment 11

[Paolo Bonzini]

I now reproduced bug 533499 too, but I was not browsing particularly fast.  In fact, I chose the message coming up with the wrong attachment from the "new mail" notification, which means I had been doing something else for at least a few seconds.

Marking as dup, but I'll add a note that the "quickly browsing" is a red herring.

Comment 12

[Paolo Bonzini]

I've not been able to reproduce bug 533499 in the last two months, and instead the situation with this bug is unbearable---I hardly ever see correct headers now.

Reopening.

Comment 13

[Ludovic Hirlimann [:Usul]]

Paolo do you have a lot of extension installed ?

Comment 14

[Paolo Bonzini]

I have Lightning and Mnenhy.  I think I saw the behavior even without them, but just to be sure I'll disable them and report.  Mnenhy could be related indeed.

Comment 15

[Paolo Bonzini]

Uh oh, https://www.mozdev.org/bugs/show_bug.cgi?id=23370