369302 - Inline images dropped in forwarded message

Status: RESOLVED WORKSFORME

(Thunderbird :: Message Compose Window, defect)

Description

[James E. Carter]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.0.9) Gecko/20061206 Firefox/1.5.0.9
Build Identifier: version 1.5.0.9 (20061207)

My neighbor received a message with inline images.  Exhibit A shows the source code, truncated to the start of the first image.  Coding for all images was present.  She forwarded the message to me.  Exhibit B shows the source code, truncated to the first IMG SRC.  Coding for images was not present. Coincidence!  I received the same message from another source.  Exhibit C shows the source code, truncated to the start of the first image.  Coding for all images was present.  I forwarded the message to the neighbor.  Exhibit D shows the source code, truncated to the start of the first image.  Coding for all images was present.

These Exhibits will be attached when the bug report has been accepted.


Reproducible: Sometimes

Steps to Reproduce:
1.  I don't know how to make it happen.
2.  In Exhibits A and B above, it happened.
3.  In Exhibits C and D above, it didn't happen.  
Actual Results:  
These are depicted in the exhibits shown above.

Expected Results:  
The coding in Exhbit B should have included the code for the inline images and should have displayed the images.

Both the neighbor and I run decent machines under Windows XP (she, Home and I, Pro) and both of us use Mozilla Firefox and Thunderbird v. 1.5.0.9.

If you need it for an HTML testcase (and if you'll tell me how), I can send you the complete source code for all four Exhibits.

Comment 1

[James E. Carter]

Attachment: Source code referred to in the bug report as ExhibitA

Comment 2

[James E. Carter]

Attachment: Source code referred to in the bug report as Exhibit B

Comment 3

[James E. Carter]

Attachment: Source code referred to in the bug report as Exhibit C

Comment 4

[James E. Carter]

Attachment: Source code referred to in the bug report as Exhibit D

Comment 5

[Mike Cowperthwaite]

So, to get this straight: only "exhibit B" doesn't show any image, right?

Note that exhibit B was created using:
  User-Agent: Mozilla Thunderbird 0.9 (Windows/20041103)
That's very out of date, more than two years old and not even an actual release.  Your neighbor should definitely upgrade to 1.5.0.9 (or whatever's current by the time she does that).  However, be aware there are other problems with forwarding certain HTML messages which have been encoded with quoted-printable -- see bug 307023 in particular.  

The MIME structure of the original (exhibit A) is complex, and exhibit C is even more so; I wouldn't mind having those as a samples even if the bug doesn't exhibit itself with a more modern version.  Save those messages as .EML files, and attach those to the bug.

Comment 6

[James E. Carter]

(In reply to comment #5)
Mike, you are correct in that only Exhibit B doesn't dislay any images.  I can't explain the Thunderbird 0.9 reference.  Both of us use Thunderbird 1.5.0.9.
I will be attaching the .eml files that you requested.  The strange thing is that, when I tried to open the .eml files with Thunderbird, the images would not display for either .eml file.  Perhaps you'll have better luck.

Comment 7

[James E. Carter]

Mike, the system wouldn't let me attach either of the .eml files.  Their size exceeds the 300 KB limit.  Do you have any other ideas?
Icidentally, we have experienced another occurrence of the same problem, this time with only one image.  Do I need to tell you about it? 

Comment 8

[Mike Cowperthwaite]

You can try to zip the files up (separately) and see if the compressed version is small enough.  If not, you can mail them (the ZIPs) to me directly.

> Icidentally, we have experienced another occurrence of the same problem, this
> time with only one image.  Do I need to tell you about it? 

Exactly how much is this "the same problem"?  Is the forwarded version truncated like the first example was?  Truncated immediately after an <img> tag?  Or is just that the image doesn't show?

As for the "0.9" userAgent string -- I know some people have set up preferences to override the string, but I don't know exactly how that's done.  Check in the Config Editor for prefs with "agent" in the name and see 

Comment 9

[James E. Carter]

Mike, not knowing what else to do, I have just let this problem cook in its own juice.  However, I have continued to play with the problem (which also continues) and I think that I have discovered a work-around that may be helpful in your debugging efforts.  What I have discovered is that, instead of using the Forward button on the task bar, if I go to the Message drop-down menu and select Forward as Inline, the message is sent complete with inline image(s).  I hope that this helps.   Jim 

Comment 10

[Joe Sherrill]

I am using version 1.5.0.10 (20070221) and I also have this problem.
If I hit Reply instead of Forward then delete the Email address and replace with addresses that I want to forward to, the Images send OK.

Comment 11

[rsx11m]

James or Mike: Can you still reproduce the problem in trunk builds November 12
or later? Unfortunately, the attached example messages are truncated and thus
not quite suitable for reproducing this. Since bug 307023 has now been fixed,
it would be good to retest if the problem still persists or can be attributed
to that bug (which would make this a duplicate).

Comment 12

[jlsdev]

version 2.0.0.18 (20081105)
Happens every time a message with inline images is either forwarded or replied to or 'edit as new' - The images are replaced with missing image placeholders.  Can set prefs->Composition to forward as attachment which 'works around' [sort of] the image issue but makes it impossible to edit out all the accumulated headers and sometimes causes confusion depending on who happens to be on the receiving end.  Ideally, as other email clients do, inline images should be attached inline the same way they were in the received email i.e. :

Content-Type: multipart/related;
	type="text/html";
        boundary=---- MULTIPART BOUNDARY

<snip>
<img src="cid:BC46DB33-50D9-4FBC-B816-494933801139"...>

---- MULTIPART BOUNDARY
Content-Transfer-Encoding: base64
Content-Id: <BC46DB33-50D9-4FBC-B816-494933801139>
Content-Type: image/gif;
	name=mime-attachment.gif
Content-Disposition: inline;
	filename=mime-attachment.gif

BASE64 ENCODED IMAGE...

---- MULTIPART BOUNDARY--


Currently sends as text/html - no multipart:

Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

<snip>
<img moz-do-not-send="true" src="ailbox:///SOME LOCAL FILE SYSTEM REFERENCE>

NOTE that the word 'mailbox' in the src= reference also has the 'm' truncated from it so even if the receiving user had access to the sending computer/filesystem [which they do not] it STILL would not work.  Perhaps a prefs->Composition setting to include inline images when forwarding/replying/etc?  Make the default to INCLUDE inline images which is what most people expect.

Comment 13

[rsx11m]

jlsdev, the effect you observe is consistent with bug 307023 and won't be fixed for the 2.0 versions, thus no need to test it with the current releases.

Note that the patch for bug 307023 has been backed out again, thus please delay any testing of the original examples until it has been resolved, then use the current 3.0b2pre nightlies to reconfirm whether it resolves the reported issue.

Comment 14

[rsx11m]

James or Mike, a new patch has been checked in for bug 307023, let's hope this fixes the problem for good. Can you verify in a current nightly 3.0b3pre build that the problem with these specific messages is gone or if it still persists?

Comment 15

[[:Aureliano Buendía]]

Reporter as in comment #14 could you try to see if it still happens with
http://ftp.mozilla.org/pub/mozilla.org/thunderbird/nightly/latest-comm-1.9.1/ or has been fixed from bug #307023?

It seems WFM here on (no truncated code in testcases).

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.4pre) Gecko/20091002 Lightning/1.0pre Shredder/3.0pre ID:20091002032130

Comment 16

[ME]

Well, it still happens with 2.0.0.23 !!

(In reply to comment #15)
> Reporter as in comment #14 could you try to see if it still happens with
> http://ftp.mozilla.org/pub/mozilla.org/thunderbird/nightly/latest-comm-1.9.1/
> or has been fixed from bug #307023?
> 
> It seems WFM here on (no truncated code in testcases).
> 
> Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.4pre) Gecko/20091002
> Lightning/1.0pre Shredder/3.0pre ID:20091002032130

Comment 17

[rsx11m]

(In reply to comment #16)
> Well, it still happens with 2.0.0.23 !!

That's because the fix hasn't been backported to 2.0 (and won't be).

Resolving per comment #15, given no response from the reporter on the request.
If anybody can still reproduce this with the given examples on 3.0b3 or later, please reopen.

-> WFM