Closed
Bug 283161
Opened 20 years ago
Closed 16 years ago
when inserting multiple inline images all appear to be the same as the last one
Categories
(Thunderbird :: General, defect)
Tracking
(Not tracked)
RESOLVED
INCOMPLETE
People
(Reporter: richard.smith, Assigned: mscott)
Details
(Whiteboard: closeme 2008-08-28)
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; Maxthon; .NET CLR 1.1.4322) Build Identifier: version 1.0 (20041206) When attaching multiple inline images to the same email message, the compose window displays a correctly formatted email. On sending however, the copy the recipient receives and the copy in the sent box are malformed. Each embedded image is replaced with the data from the very last embedded image originally attached. I maintain two dozen copies of Thunderbird and can only reproduce this problem on one system. Reproducible: Always Steps to Reproduce: 1. Compose a new email 2. Add 2 embedded images using, Insert / Image 3. Send Actual Results: The compose windows looks good but the copy sent is mangled to have the last image embedded take over all the others Expected Results: Faithfully encoded each file properly
Comment 1•19 years ago
|
||
I have a similar problem. When I compose an email and "insert" a graphic image into the text of the email the compose window is ok. Once the email is sent no image appears in the email. I have 2 email accounts set up seperately (no under Local Folders). This happens in bth accounts. This first happened in Netscape 7.1. I used 7.1 for years then all of a sudden the "insert image" command stopped working as I described above. I upgraded to Thunderbird version 1.0.6 (20050716)this week and the problem migrated over with my Netscape 7.1 profile. I then created a new profile in Thuderbird, set up my 2 email accounts and the same thing happened. I have been a Netscape user since it first started and never had a problem with the insert image command until Netscape 7.1. It worked fine in 7.1 for years and then suddenly stopped working.
| Reporter | ||
Comment 2•19 years ago
|
||
I am seeing this behaviour on one of my Thunderbird (1.0.2) too. The last image is present in the sig file. When another embedded image is sent, though the filenames in the message source differ, the encoded attachment is identical.
Comment 3•19 years ago
|
||
Hi The same thing happens with my thunderbird version too. I have found this thing when used TB 1.0.6, so I have uninstalled it and installed version 1.0.7, but the problem didn't disappear. :( I have only checked the sent emails' source and found that there are 2 image parts with the same content, so it seems, that TB fails to create the email correctly, the last image will be everywhere. I have firstly seen this problem, when I tried to forward an email with inline images and at the forward email composition I have inserted my signature with an image in it. The recipients get the email with this image in it everywhere. Then I tried to create emails with 2 inline images, the same thing happens.
Comment 4•19 years ago
|
||
(In reply to comment #0) > Steps to Reproduce: > 1. Compose a new email > 2. Add 2 embedded images using, Insert / Image > 3. Send These steps are actually a little vague. When you Insert | Image there are a lot of potential steps that could be taken at this point. See bug 333838 -- in that case, the multiple images that were inserted all actually had the same filename; the image was overwritten on disk between Inserts. Does that situation apply to this bug?
Updated•18 years ago
|
QA Contact: general
Comment 5•16 years ago
|
||
Reporter, does the issue still occur with the latest supported 2.0.0.x / Shredder trunk nightlies? (1.5.0.x is now end-of-life and the latest supported Thunderbird version 2 is 2.0.0.16)
Whiteboard: closeme 2008-08-28
Comment 6•16 years ago
|
||
RESO INCO per lack of response to the last question. If you feel this change was made in error, please respond to this bug with your reasons why.
Status: UNCONFIRMED → RESOLVED
Closed: 16 years ago
Resolution: --- → INCOMPLETE
You need to log in
before you can comment on or make changes to this bug.
Description
•