Open Bug 1062943 Opened 10 years ago Updated 2 years ago

Sender signature image replaced in reply


(Thunderbird :: Message Compose Window, defect)

31 Branch
Windows 7


(Not tracked)



(Reporter: deferble, Unassigned)


User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Firefox/31.0
Build ID: 20140716183446

Steps to reproduce:

This issue is really complicate to reproduce as it seems there's some random factor.
When am email is received containing inline images in previous email in threat, sometime, during the reply composition (just when reply is done an no editing already done), previous inline images of previous email is replaced with other image. Its seems this other image is taken from local TB cache of images.

Although it is really random it seems also (although not checked due the randomness) the image "used" in the replacement could be always the same.

Actual results:

After some expeculations and guessing (just in case devel team could help) it seems inline images do not have filename as is, so, when TB receives an email with inline images it takes the b64 inline in img tag and puts at the end of the email the b64 data with idref from the img tag.

When there's a thread of emails (reply to reply) it seems (analyzing the HTML created each reply) that only the inline images at the end have filename="aaaaaa.extfile", where the "aaaaaa" seems to be a random name used byt TB for locating the file and "extfile" is simply the png, gif or jpg extension.

My expeculation is that TB creates the random file and uses this name in a way where the created name (by the sender client) and received name (the names already in our cache) without considering that could be collisions, due the short used names.

The idea is the following:
A send email to B with inline image (named aaaaaa.jpg).
B replies this email to B with inline image in original email aaaaaa.jpg, and adding new footer with aaaaab.jpg image.
A receives the email and replies again, but when composing the email the aaaaab.jpg in its cache is used (instead that coming in the email) and aaaaab.jpg is other so will replying changed the aaaaab.jpg with the incorrect one.

Expected results:

The reply should never use cache local images and always coming images in the email itself.
I think this is the same as bug #766495
i can confirm! bug still exists in current version: 45.3.0
I received an email with an image in a footer, but the image was not included. When i replied my TB replaced the missing image with some random image!
The same error on Linux 45.3.0, also on Windows, many users are affected.
**** happened again today! I dont even know about the bug before RECEIVER tells me.. in the reply window everything is fine.. but receiver receives different image then he should!
Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.