755176 - Attachments for a message display with the body of another message (slow connection)

Status: UNCONFIRMED

(Thunderbird :: Message Reader UI, defect)

Description

[francis.p.jones]

User Agent: Mozilla/5.0 (X11; U; Linux i686; en-us) AppleWebKit/531.2+ (KHTML, like Gecko) Version/5.0 Safari/531.2+ Ubuntu/10.10 () Epiphany/2.30.2

Steps to reproduce:

I have a slow connection to an IMAP server, from China to US.  When I clicked on a message with 3 .jpg attachments (total size about 1.3 Mb) it took a while to load, so I moved the cursor to highlight  a smaller message which was just pure text (6kb).


Actual results:

I got the pure text of the message I focused on, but I ALSO got attachments --- the 3 .jpgs of the previous message which I'd been trying to download.  After waiting for a bit, I was able to click on those .jpg's and the images displayed fine, all the while that I was still focused on the pure text message (which had no attachments at all).


Expected results:

I think that if I focus on a message, I should get only that message, and not a mixture of the focused message plus parts of another message.

Comment 1

[WADA:World Anti-bad-Duping Agency]

Phenomenon you saw is same as a phenomenon of bug 538803 or and bug 533499.
It's not "attachments of a mail is displayed with the body of another message".
Cause is perhaps slownes which is seen in bug such as bug 719751 .
It's a contention of following when slow loading of previous mail;
  (1) Previous mail(mail-1) display   (2) Newly clicked mail(mail-2) display
      (1-a) header pane display           (2-a) header pane display            
      (1-b) message pane display          (2-b) message pane display
      (1-c) attachment pane display       (2-c) attachment pane display 
A phenomenon of bug 533499. 
If mail-1 is clicked then mail-2 is clicked quickly, following looks to happen.
  (1-a), (1-b), (2-a), (2-b) is executed in this order.
  (2-c) is executed earlier than (1-c), and it's blank because no attachment.
  (1-c) is executed later.
In worst case, if all of (2-a)/(2-b)/(2-c) somehow fails(timeout etc.), following may happen.
   mail-1 is shown at header/message/attachment pane.
   selected mail at thread pane is mail-2.
So, it looks for user "wrong mail is displayed".

This phenomenon is usually observed with offline-use=Off, and I think it is rarely observed usually if offline-use=On even when slow IMAP. (auto-sync=enabled, and folder's Properties/Synchronization, offline use = chcked = On)
Do you set offline-use=Off?

Comment 2

[francis.p.jones]

The folder in question has "select this folder for offline use" checked.  So, no, offline-use=On.

I agree that the problem probably arises from slow connections.

I also suspect that indicates that the mechanism for displaying of messages isn't setting the displayed message to null properly when focus shifts.

Comment 3

[WADA:World Anti-bad-Duping Agency]

"Slowness in IMAP connection" is multiplied by bug 740453. Because you use Mac(line ending=CR instead of CRLF of IMAP spec), bug 740453 occurs even when IMAP server returns correct RFC822.SIZE.

Do you see problem in your environment even with "View/Message Body As/Plain Text" and "View/Display Attachments Inline is Unchecked=Off=Disabled"?

Comment 4

[francis.p.jones]

I'm not using a Mac at this time.  I'm using a generic store-bought PC and running linux (ubuntu).

Because the problem happens rarely ... again, probably related to downloading slowness... I haven't been able to reproduce the problem.  This result probably has no weight however.

Will continue to try to reproduce.

Comment 5

[Ludovic Hirlimann [:Usul]]

(In reply to francis.p.jones from comment #4)
 
> Will continue to try to reproduce.
Any luck ?

Comment 6

[WADA:World Anti-bad-Duping Agency]

Setting depeency to bug 719751, for ease of tracking and analysis.

Comment 7

[Wayne Mery (:wsmwk)]

wada, is this appropriate for bug 714489 meta bug?

Comment 8

[Wayne Mery (:wsmwk)]

Francis, if you are still using a current version of Thunderbird under the same conditions, it would be useful to know whether you still see this problem

Comment 9

[francis.p.jones]

Wayne, sorry I'm not using TB these days. A few years ago I had trouble with TB on my phone, and searched for a solution that would work on both the phone and on my macbook. So I'm using Spark these days. I still use TB on my linux machines, but I'm in the UK for the next few months and my linux machines are in Shanghai.

Comment 10

[francis.p.jones]

i'll see if i can get access thru another channel.

Comment 11

[aamirift]

The issue still persists as of 11/09/2020 using 68.12.0 (64-bit)

Comment 12

[Niklas Beisert]

I've seen the issue for a long while and it persists today (2024-05-21) on a plain Debian 11 / Cinnamon installation:
User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:115.0) Gecko/20100101 Thunderbird/115.11.0
Build ID: 20240513132046
OS: Linux 5.10.0-29-amd64 #1 SMP Debian 5.10.216-1 (2024-05-03)
OS Theme: Adwaita / Adwaita

The particular setup is a Thinkpad T480s laptop, 16GB RAM, i7-8650U CPU @ 1.90GHz × 4; Thunderbird with IMAP connection to a localhost dovecot mail server, thunderbird messages not saved for offline use, using mailbox directory format. The issue mostly occurs when moving between messages in the main message tab and in connection with large attachments. It does not happen regularly, but also not infrequently. Connection speed should not be an issue here, but the decoding and preparation of attachment data could take some fractions of a second, i.e. in which time a new message might be selected.

I wonder if the following happens: The decoding of attachment is delayed to the background in order to be able to display the message body without delay. This might be desirable behaviour. When the decoding is done, the attachment will be added to the current message tab irrespectively of whether the displayed message body has changed in the meantime. If that's how things work, TB should make sure that the attachment display is added only if the message is still the one that the attachment belongs to and/or kill the background processing right away when the selected message changes.

Displaying a message in one window along with attachment data that actually belongs to a different message appears to represent a serious security issue: One might try to exploit the bug by sending a large malicious file and hoping that the recipient would open the attachment when it is mistakenly displayed from another but genuinely harmless message.