TB 3a1-0831, 2a1-0901, 1.5.0.5 Open a .EML file for a multipart/related message that's text/html with an embedded image. Select Reply, Forward-Inline, or Edit-As-New to create a new HTML compose window: the image does not appear in the compose window. The problem is invalid escaping of the URL into the file Example: source of the original message: <img src="cid:part1.09090902.03040708@well.com" title="" alt="An example" width="225" height="200"><br> Source of the reply in the compose window: <img moz-do-not-send="true" src="file:///<path>msg.eml ?header=quotebody&amp;part=1.2&amp;filename=ex01.png" ~~~~~ ~~~~~ title="" alt="An example" height="200" width="225"><br> Also, I don't think that moz-do-not-send belongs there either. Source of the Edit-As-New compose window: <img src="file:///<path>msg.eml ?fetchCompleteMessage=true&amp;part=1.2&amp;filename=ex01.png" ~~~~~ ~~~~~ title="" alt="An example" height="200" width="225"><br> Source of the forward-inline compose window: <img moz-do-not-send="true" src="file:///<path> ?fetchCompleteMessage=true&amp;part=1.2&amp;filename=ex01.png" ~~~~~ ~~~~~ title="" alt="An example" height="200" width="225"><br> This is very similar to bug 307023, but with a different source. Also bug 224733.

If we offer a means to save compositions in the the eml format... (don't know why we do that except for compatibility with OE) ...For those that compose and send in html, the eml implementation is a complete disaster.

Since our company installs Thunderbird for +1500 clients and this bug is being reported to us many times and we are held responsible for the software we install. I would like to ask to consider the importance of the bug. Why: We created an addon for Thunderbird allowing our clients to save e-mails from Thunderbird to our office management program (save e-mails project related on a server). From our software they open the saved EML's to read/reply/forward them using Thunderbird. This is appearently unusable for the moment because the images (even in signatures) are invisible. This is an attempt of our company to let professionals use Thunderbird in a specific sector (Architects) in Belgium, The Netherlands, Luxembourg, France and Germany. We hope this bug will be fixed soon. This is the only bug that's making it difficult to use Thunderbird for our customers. We would like to keep promoting Thunderbird instead of switching to an alternative. If I can help in any way fixing this error, I am at your disposal.

Bug 307023 seems to be fixed. Is this bug 351109 still an issue in Thunderbird 7? If yes, can you attach a sample eml file what has the problem?

sadly, I don't think this is fixed by the fix for bug 307023. But I will look at it.

I don't think this is an escaping issue; I believe it has to do with the fact that we're not converting the file: url to a mailbox url in the quoting case.

this fixes .eml handling of reply/forward inline of messages with inline images, modulo bug 692875.

Comment on attachment 566090 [details] [diff] [review] this fixes reply and forward/inline edit message as new for .eml files This goes along with the fix in bug 692875, in that you need that fix applied to see that saving a message as a draft after replying to a .eml file works.

Comment on attachment 566090 [details] [diff] [review] this fixes reply and forward/inline edit message as new for .eml files >+ nsCString origMsgUri(originalMsgURI); >+ origMsgUri.Replace(0, 5, NS_LITERAL_CSTRING("mailbox:")); >+ origMsgUri.Append(NS_LITERAL_CSTRING("?number=0")); >+ mOriginalMsgURI = origMsgUri; This is really confusing. It turns out that this method is only ever called from BuildQuotedMessageAndSignature, and curiously it always passes mOriginalMsgURI.get() and mWhatHolder, and the latter is always 1! I would just ignore originalMsgURI (and possibly also "what") at this point, modify mOriginalMsgURI in-place, and remove BuildQuotedMessageAndSignature in a followup bug. r=me with that fixed. Nit: mOriginalMsgURI.AppendLiteral("?number=0"); (happens several times)

fix checked in, with Neil's comments addressed - http://hg.mozilla.org/comm-central/rev/8867ea4e1147