Last Comment Bug 685794 - Thunderbird is messing up messages. First view source : (A. other mail's body) + (B. this mail's whole mail data). Second view source : correct (B. this mail's whole mail data)
: Thunderbird is messing up messages. First view source : (A. other mail's body...
Status: RESOLVED DUPLICATE of bug 823838
dupme
: qawanted
Product: Thunderbird
Classification: Client Software
Component: Message Reader UI (show other bugs)
: unspecified
: All All
: -- major (vote)
: ---
Assigned To: Nobody; OK to take it and work on it
:
:
Mentors:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2011-09-09 00:05 PDT by Sander Lepik
Modified: 2012-12-20 23:56 PST (History)
9 users (show)
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---


Attachments
Messed up message view (178.86 KB, image/png)
2011-09-09 00:05 PDT, Sander Lepik
no flags Details

Description Sander Lepik 2011-09-09 00:05:19 PDT
Created attachment 559391 [details]
Messed up message view

It happens more often when changing folders.

1. Read message in one folder.
2. Switch to another folder and open message.
3. Message contains some fractions from previously opened message (see attachment, mikala in the beginning is from another message, has nothing to do with linkedin) and content is not shown. I can see source instead.

To see the message correctly i have to choose another message from the same folder and then switch back to the message i want to read.

It has happened for quite some time and affected are Thunderbirds since 3.x i think. Probably at the time when new headers came to play.

I'm using IMAP. And i think that Thunderbird should wait until the message is loaded in the backround and then start to display it. Currently it's doing something very weird :/
Comment 1 WADA 2012-01-04 18:34:44 PST
With which release or build of Tb?
IMAP folder of offline-use=On? Or offline-use=Off? (Folder Properties/Synchronization, both previously used folder and switched folder)

When did you execute "view a mail in a folder" and "switch to other mail folder"?
Just after new mail arrival at both "a mail folder" and "switched mail folder"?
Is mail you saw before folder switch large mail?(big attachmnts or embed resource such as PDF, JPEG)?
If so, was the mail fully shown at message pane and attachmnt pane before you switched mail folder?

What is your "max chached connections"? Do you enable IDLE command use? (Server Setting/Advanced)

If default value of max cached connections, it's 5. And Tb holds two connections for Inbox and Trash, and uses other three connections for other folders. So, even when three connections were used like next(assume that you switched from FolderA to folderB),
  1-st : For Inbox, used for request which doesn't need "select mbox"(e.g. STAT).
  2-nd : For Trash, used for request which doesn't need "select mbox"(e.g. STAT).
  3-rd : folderA which is currently selected and mail data is being fetched
  4-th : folderX for fetch of header of new mails by automatic new mail check
  5-th : folderY for fetch of whole mail data by auto-sync
Tb doesn't always use 3-rd connection for newly selected FolderB.
However, because Tb has problem in detection of the conection loss while IDLE and IDLE command is re-requested after 29 minutes, if connection is lost while IDLE processing, such connection may be unusable when you requested folder swtch from FolderA to FolderB. In his case, Tb may kill fetch process at 3-rd connection for FolderA and may start fetch process for FolderB. If available connection is only one, it always happens.

If such condition occurs, similar phenomenon to bug 587528 may happen.
  bug 587528 : partial data of a mail + whole mail data of the mail
            Perhaps, message body data by fetch on demand upon new mail arrival
            + whole mail data by mail click just after new mail arrival
  your case  : partial data of previous mail + whole mail data of switced mail
 
When you saw problem, how many TCP connections were establshed with th IMAP server? Did TCP connection of TIME-WAIT, CLOSE-WAIT status remain?
  At command prompt : netstat /n /b /o

> I can see source instead.

Does it mean View/Message Source showed correct mail data?
Or mail source for corrupted display in screen shot was shown?
 
If source for corrupted display, can you attach .eml file when problem happens? (save as .eml, and attach .eml file, after replace/remove personal information. Never paste if long data, please). 
Message source of previously shown mail is also required, because we need to know which part of the mail was merged to switched mail.

When you saw problem again, check next please, if offline-use=on folder.
  Go Work Offline, "Not download" for dialog,
  View the two mails in FolderA and FolderB.
  View/Message Source of the two mails.
If whole mail data is not downloaded by auto-sync yet, Tb shows "message is not downloaded yet" like message at message pane.
Check "netstat /n /b /o" also, please.
Comment 2 Sander Lepik 2012-01-05 02:36:42 PST
(In reply to WADA from comment #1)
> With which release or build of Tb?
Currently with Tb10

> IMAP folder of offline-use=On? Or offline-use=Off? (Folder
> Properties/Synchronization, both previously used folder and switched folder)
Currently both off. But i have some folders where it's on and it still happens. So i don't think it's dependent on that option.

> When did you execute "view a mail in a folder" and "switch to other mail
> folder"?
> Just after new mail arrival at both "a mail folder" and "switched mail
> folder"?
Probably yes. It seems to happen most often when some mail is just arrived.

> Is mail you saw before folder switch large mail?(big attachmnts or embed
> resource such as PDF, JPEG)?
No.

> What is your "max chached connections"?
5

> Do you enable IDLE command use?
Yes.

> When you saw problem, how many TCP connections were establshed with th IMAP
> server? Did TCP connection of TIME-WAIT, CLOSE-WAIT status remain?
>   At command prompt : netstat /n /b /o
# netstat -antp |grep thunder
tcp        0      0 10.1.7.1:58031              209.85.173.108:993          ESTABLISHED 14157/thunderbird-b 
tcp        0      0 10.1.7.1:52084              209.85.173.108:993          ESTABLISHED 14157/thunderbird-b 
tcp        0      0 10.1.7.1:44351              10.1.21.19:8080             ESTABLISHED 14157/thunderbird-b 
tcp        0      0 10.1.7.1:57710              209.85.173.108:993          ESTABLISHED 14157/thunderbird-b 
tcp        0      0 10.1.7.1:43697              209.85.173.109:993          ESTABLISHED 14157/thunderbird-b 
tcp        0      0 10.1.7.1:45283              209.85.173.108:993          ESTABLISHED 14157/thunderbird-b
> 
> > I can see source instead.
> 
> Does it mean View/Message Source showed correct mail data?
Yes, source seems to be from selected mail. Isn't the same as displayed in message body. (Comment after creating example: better look at example, even source can be mixed up :S)


=======
Now if i look more into it.. It's not even mail from previous folder but probably last arrived mail or something like that.

Example:

* What i see in message body when i switch back to inbox: http://pastebin.com/Y6APRV6Z

* View source output (now it gets ridiculous :S during writing this reply few more mails landed): http://pastebin.com/wPV3zP3X

* Close view source and reopen it (this seems to be correct source now): http://pastebin.com/LLZsJGnL

* What i should see in message body: http://pastebin.com/qQ0fQU8r

===

So to me it seems that Tb is picking up some random other message bodys (probably last arrived mails) and is inserting them into some buffer before it is presented to user. This should not happen! (When i wait a bit before opening mail, buffer gets cleared and only the message i want to see is shown).

I also think that many users are not affected as they probably don't use filters as much as i do. (Filters run in another computer that is also using Tb - its only job is to filter my mail).
Comment 3 Sander Lepik 2012-02-08 03:05:29 PST
ping
Comment 4 Magnus Melin 2012-02-22 13:19:47 PST
Did you tru "repair folder" in the folder properties?
Comment 5 WADA 2012-02-22 16:21:17 PST
First view source : (A. other mail's body) + (B. this mail's whole mail data)
Because B. is shown by second "View Source", fetch is executed normall by the second "View Source".

It looks a variant of bug 587528 and bugs listed in dependency tree for that bug. 
   Shown data = (a. this mail's body) + (B. this mail's whole mail data)
I may be pheomeon like next. (See bug 726469 comment #5)
1. Two new mails arrives at sane time. Call UID 11 & 12.
  => (i)  UID 11 fetch body[text] with 2KB size limit for preview of new mail.
  => (ii) UID 12 fetch body[] by message filter with Body, or by mail click.
2. data of (i) and 8ii) is merged

What is UID of relevant mails?
(value in "Order Received" column is UID if IMAP folder)
What is sort order at thread pane? Is newest mail shown at top? Is newest mail always shown at message pane when foldeer is opened?

bug 6857948this) bug and bug 726469 is offline-use=Off case, so "affect by auto-synch" is surely ruled out. Setting dependency for ease of tracking/analysis/search.
Comment 6 Sander Lepik 2012-02-24 07:14:31 PST
(In reply to Magnus Melin from comment #4)
> Did you tru "repair folder" in the folder properties?

Didn't help.
Comment 7 WADA 2012-07-15 16:15:15 PDT
(In reply to Sander Lepik from comment #6)
> > Did you tru "repair folder" in the folder properties?
> Didn't help.

If "Repair Folder" doesn't help and problem is persistent on the mail, it may be "re-fetch by Tb while Tb is fetching mail data" due to bug 921118(incorrect RFC822.SIZE). 
If problem is timing dependent, phenomenon of bug 740453(occurs even when RFC822.SIZE is correct) may be relevant to "re-fetch by Tb while Tb is fetching mail data".
Comment 8 Sander Lepik 2012-07-15 22:56:51 PDT
(In reply to WADA from comment #7)
> (In reply to Sander Lepik from comment #6)
> > > Did you tru "repair folder" in the folder properties?
> > Didn't help.
> 
> If "Repair Folder" doesn't help and problem is persistent on the mail, it
> may be "re-fetch by Tb while Tb is fetching mail data" due to bug
> 921118(incorrect RFC822.SIZE). 
> If problem is timing dependent, phenomenon of bug 740453(occurs even when
> RFC822.SIZE is correct) may be relevant to "re-fetch by Tb while Tb is
> fetching mail data".

There is no such bug as 921118. Typo?
Comment 9 WADA 2012-07-16 00:00:44 PDT
Sorry for typo. It's bug 92111.
Comment 10 Sander Lepik 2012-07-16 00:21:58 PDT
Ok, both are targeted for tb16. I'll test it when it hits Earlybird and report back.
Comment 11 Sander Lepik 2012-07-25 05:01:23 PDT
This bug seems to be fixed in tb16. So it's closed case for me. Feel free to reopen.. :)
Comment 12 WADA 2012-12-20 23:56:14 PST
Closing as dup to consolidate to single bug.

*** This bug has been marked as a duplicate of bug 823838 ***

Note You need to log in before you can comment on or make changes to this bug.