Closed Bug 487905 Opened 15 years ago Closed 15 years ago

forward html email with embedded images renames image locations incorrectly

Categories

(Thunderbird :: Message Compose Window, defect)

x86
Linux
defect
Not set
normal

Tracking

(Not tracked)

RESOLVED DUPLICATE of bug 307023

People

(Reporter: bugzilla, Unassigned)

Details

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-GB; rv:1.9.0.8) Gecko/2009032711 Ubuntu/8.10 (intrepid) Firefox/3.0.8
Build Identifier: version 2.0.0.21 (20090318)

When forwarding on a HTML email from an IMAP account, embedded objects such as images appear to be missing.
Checking further it would appear that the image locations are being changed when the forward option is used to fetch them from the imap account and just show as broken links
eg:
imap://xxx.xxxx%40xxxxxxxx%2Eco%2Euk@mail.googlemail.com:993/fetch%3EUID%3E.INBOX%3E4223?part=1.1.4&filename=ATT4624267.jpg
If the reply option is used rather than the forward option then the email/html is copied intact and the images can be seen and forwarded correctly.
Also tested against Windows thunderbird

Reproducible: Always

Steps to Reproduce:
1.Receive HTML email with embedded images (ie not attachments)
2.Forward email
3.Before sending you will see that the images have been replaced with broken links
Actual Results:  
Image placeholders are seen as broken links and the images themselves have been stripped from the image

Expected Results:  
HTML email should be left intact - as happens if the reply option is used rather than forward
Works for me in current trunk nightly builds with 7bit-encoded HTML part.

Is the text/html part using a Content-Transfer-Encoding: quoted-printable?
You can check this with View > Message Source in the original message.

If yes, that's likely a duplicate of or at least related to bug 307023.
you are correct about the context type:

X-Mailer: Apple Mail (2.930.3)
To: undisclosed-recipients:;


--Apple-Mail-5-990071371
Content-Type: text/plain;
	charset=US-ASCII;
	format=flowed
Content-Transfer-Encoding: 7bit

--Apple-Mail-5-990071371
Content-Type: multipart/related;
	boundary=Apple-Mail-6-990071372;
	type="text/html"


--Apple-Mail-6-990071372
Content-Type: text/html;
	charset=US-ASCII
Content-Transfer-Encoding: quoted-printable
That structure indeed should trigger bug 307023, where the only difference I can see is the type="text/html" attribute in the multipart/related headings and the fact that "imap://" at the begin of the reference remains intact in the Folder Properties dialog (or was that copy-pasted from the received message?).

To verify if it's really a duplicate, can you forward the message to yourself and then copy-paste the content of the <IMG SRC=...> tag (with all attributes) from message source of the text/html part as received?
Please accept my apologlies - you are right the i of imap is missing. I removed the email addresses for security and it is possible that I have stupidly added the I.

I confirm your suspicion that it is the same that the first character is missing.

<img moz-do-not-send="true"
 src="map://xxx%2Exxxx%40ixxxxx%2Eco%2Euk@mail.xxxxx.co.uk:993/fetch%3EUID%3E.INBOX%3E4223?part=1.1.2&amp;filename=ATT4624265.jpg%22"
 height="73" width="91"></div>
Ok, thanks and no problem. That should be unambiguous then.
Status: UNCONFIRMED → RESOLVED
Closed: 15 years ago
Resolution: --- → DUPLICATE
just one thing I noted and I don't know if this is related, some of the following tags are also missing their first letter.
For example: 

--- original html ----
<div=
 style=3D"word-wrap: break-word; -webkit-nbsp-mode: space; =
-webkit-line-break: after-white-space; "><div><span =
class=3D"Apple-style-span" style=3D"border-collapse: separate; color: =
rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: =
normal; font-variant: normal; font-weight: normal; letter-spacing: =
normal; line-height: normal; orphans: 2; text-align: auto; text-indent: =
0px; text-transform: none; white-space: normal; widows: 2; word-spacing: =
0px; -webkit-border-horizontal-spacing: 0px; =
-webkit-border-vertical-spacing: 0px; =
-webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: =
auto; -webkit-text-stroke-width: 0; ">

---- forwarding email -----
<div style="" break-word;="" -webkit-nbsp-mode:="" space;=""
 -webkit-line-break:="" after-white-space;="">
<div><span class="pple-style-span&quot;" style="" separate;="" color:=""
 rgb(0,="" 0,="" 0);="" font-family:="" helvetica;="" font-size:=""
 12px;="" font-style:="" font-variant:="" font-weight:=""
 letter-spacing:="" line-height:="" orphans:="" text-align:=""
 text-indent:="" text-transform:="" white-space:="" normal;=""
 widows:="" 2;="" word-spacing:="" -webkit-border-horizontal-spacing:=""
 -webkit-border-vertical-spacing:="" 0px;=""
 -webkit-text-decorations-in-effect:="" none;=""
 -webkit-text-size-adjust:="" auto;="" -webkit-text-stroke-width:=""
 0;="">

I noticed that DIV has been corrupted and it appears that all of the tags have been shifted one character to the left. For example the style is no longer in quotes and th the SPAN tag does not have the class
class=3D"Apple-style-span"

but has <span class="pple-style-span&quot;"
Yes, that's part of the bug. The issue is that, with quoted-printable set, the recoding of the escape sequences (e.g., "=3D" for '=') is done twice, thus interpreting the characters following a '=' as hexadecimal numbers.
You need to log in before you can comment on or make changes to this bug.