(This bug imported from BugSplat, Netscape's internal bugsystem. It was known there as bug #339514 http://scopus.netscape.com/bugsplat/show_bug.cgi?id=339514 Imported into Bugzilla on 02/04/99 15:49) Reported by Esther Goes (esther@netscape.com) Build: Win32 Jan 11a Nova 4.51 US Pro build installed on Compaq P133, NT 4.0 SP 4 Win32 Nov 20b RTM 4.5 US Pro build installed on Compaq P133, Windows 98 PPC Nov 20.2 RTM 4.5 US Pro build installed on PPC 8500/180, OS 8.5.1 (This is Not a regression) Problem: Communicator has a problem performing a 'Forward->Inline' to a Outlook Express sent message(RTM version 4.72.3110.5) that contains a inserted graphic image such as a gif. When Communicator 4.5 RTM or 4.51 tried to Forward->Inline this message, it displays a portion of the mine information that is normally hidden, fails to display the image, and does not wrap correctly. If you try to send this message, it displays an error message that it couldn't find the image. The message reads, "Netscape couldn't prepare the file C:\TEMP\nscomm40\temp\tmp2\3D"cid001a01be3f23$7fa88b70$8d280cd0@reliant.mcom.com " for sending. Make sure the file is in the correct location. If you continue, C:\TEMP\nscomm40\tmp\tmp2\3D"cid:001a01be3f23$7fa88b70$8d280cd0@reliant.mcom.com " won't be sent with this page. --OK-- --Cancel-- " Communicator does not crash if you click OK and the message is received as it was displayed in the HTML Message editor. Work around: From Communicator, you can Forward as Attachment or Forward Quoted the message. Once you Forward the message as Attachment or Quoted once, you can Forward Inline the fwd message. Note: This problem is NOT a regression. This problem behaves the same on Nova 4.5 RTM. This is a cross platform problem since I can reproduce the problem on PowerPC Nov 20.2 Nova 4.5 RTM build. Steps to reproduce problem: 1) From Outlook Express (v4.72.3110.5), Start a new message. (My setting are: Under the Tools->Option pref "Sending" tab, I have it sent mail as HTML with the HTML setting set to send MIME message encoded text as "Quoted Printable". UNcheck for All for 8 bit character in header. Checked for pictures with messages. Checked for Indent messages on reply.) 2) Address message to yourself and type in a Subject title 3) Insert your cursor in the message body then select the Insert menu and choose the "Picture" option. The Picture dialog appears 4) Click on the Browse button 5) Choose a Gif file then click OK. Your image should now be displayed in the compose window It is not necessary to type any text but it is necessary to insert a image to see problem. 6) Send the message -- 7) From Communicator, retrieve the message 8) Select the message. The message is displayed correctly 9) Try to Forward->Inline the message The message is displayed incorrectly and the image is shown as a broken link. Here is what I see... " -------- Original Message -------- Subject: Hi peter - just an inserted image Date: Wed, 13 Jan 1999 10:35:31 -0800 From: 3qatest07@netscape.com (3qatest07 testaccount-lchiang) To: "Peter J Mock" ------=_NextPart_001_0023_01BE3EE0.71E10000 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable ------=_NextPart_001_0023_01BE3EE0.71E10000 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable= ------=_NextPart_001_0023_01BE3EE0.71E10000-- "

I posted a test message on my home directory located at: http://jazz/users/pmock/publish/bug339514/ I also installed the latest Win32 Jan 13a 4.51 US Pro build just to check. It exhibits the same problem.

Actually, Esther's email is "esther@netscape.com" --- Thanks Lisa, I updated the bug description. /Peter Mock

TFV to 5.0

Jefft - why did you mark this Remind? Will you be looking at all your 5.0 remind bugs later on?

Yes, I marked it as remind because we don't have the code for doing the forward inline yet. And, I don't really know what will it look like. I guess remind isn't a good resolution then.

It's perfectly ok to just leave this bug in the "new" status until you're actively working on this part of the code. OK?

The main reason I changed it to Remind because I kept getting auto-reminder messages from terry daily which drives me crazy.

Jeff- can't you filter those auto reminder msgs?

This is something we should look at /investigate for 5.0. Jeff - I'm going to reopen this now. To not get the auto-reminder, you can probably just mark the bug "assigned" Thanks.

I am reassigning this hot potato to Rich. He does mime nowadays. :)

Just marking this for post M10. Will spend time on these after the majority of the core is functional. - rhp

I don't think this bug would stop us from shipping PR1. Rich - do you think you will be looking at this before your long vacation? By the way, the behavior is really strange. Replying (which quotes the message authored in OE5) works fine. It's just forward inline that behaves badly.

4.x and 5.x code bases are so different that we wouldn't really be fixing this bug, but rather implementing from scratch. In fact, jefft is going to be working on this while I'm out so I'll assign it over to him. Thanks jeff! - rhp

Not a beta stopper.

Peter, would you retest this 4.5-era bug with mozilla? Thanks.

Sure Phil. I will re-test shortly.

Using the following builds, ftp://sweetlou/products/client/seamonkey/windows/32bit/x86/2000-01-25-20-M13/sea monkey32e.exe ftp://sweetlou/products/client/seamonkey/unix/linux_glibc/2.2/x86/2000-01-25-20- M13/netscape-i686-pc-linux-gnu.tar.gz ftp://sweetlou/products/client/seamonkey/macos/8.x/ppc/2000-01-26-03-M13/netscap e5-mac-M13.sea.bin seamonkey does not fail with an error message when forwarding inline a outlook express mail message. It allows you to send the message but the inserted image is not displayed inline. There's no broken link and it display part of the message header in the message body. I will attach a sample outlook express 5.0 mail message.

Rich & JF, do you want to take this one? It doesn't seem belong to me anymore.

You can throw it my way. - rhp

Off to Rich. Thanks, Rich.

not beta2 stopper either.

Taking the lead from Product Marketing. - rhp

reassigning to ducarroz

*** Bug 76530 has been marked as a duplicate of this bug. ***

As noted in bug 76530, the problem is that the content-type of the message itself is (e.g.) image/jpeg, rather than text/plain. If the content-type is multipart/mime and there are image attachments, it's fine. Also note, Outlook/Exchange Server do this too, not just Outlook Express. The attachment in 76530 is from an Exchange Server user.

I recently had a problem described in this bug and did some more research. In my case, there's also a crash. It seems that Mozilla incorrectly tries to forward messages inline even if the top-level media type of message body isn't text or multipart. I tried to forward a mail message with the "Forward messages: inline" method. The message's body had content type image/jpeg. I can reproduce the problem everytime, but crash occurs only with one specific message - maybe its headers or size matters. The steps I need to take to reproduce the problem: 1. Select the message in inbox 2. Press the "Forward" button What happens: Mozilla apparently tries to insert the contents of the JPEG image into the text of the message, thus the content of the forwarded message consists of: - Quoted headers of the original message, - First 4 bytes of JPEG header (that is, "ÿØÿà". I don't know if those won't be stripped during submission. Their hex codes are FF D8 DD E0.) I would expect the message body to be attached as a file instead of placed inline if its content type's top level media type isn't "text" or "multipart" That is, "application", "image", "video" etc. should be forwarded as attachments regardless of "Forward messages:" pref setting. For description of MIME media types, refer to rfc 2046, http://www.ietf.org/rfc/rfc2046.txt. Another problem is the crash I experience with one of such messages. I just need to click "Forward" and then close message composition window. After clicking "Don't save" Mozilla crashes. Sometimes it doesn't crash the first time and I need to switch a little between messages in the folder and try to forward and close again. Sometimes several cycles are needed before Mozilla crashes. Talkback IDs are: TB338757Y TB338559Y TB338509K TB338396Q TB337563G TB333494K TB333416W TB341657Q I'm trying to assemble another, different message that would cause a similar crash, but haven't succeeded as of now. I'll attach that message so you can try to reproduce the crash.

CCing myself

I also checked that if it doesn't crash the first time, I don't need to switch between messages. I just need to repeat the "Forward/Close/Don't save" cycle again, and again, until Mozilla crashes.

Oops, attachment 61292 [details] was the wrong file, it contained some SMTP session trash. Use attachment 61294 [details] instead.

It seems that the length of headers has some influence on reproduceability. I have prepared two messages that do crash, but they differ in the number of tries needed to crash and in the length of their "From", "To" and "Subject" headers only. I'll attach those messages in a while. They wille be codenamed "test 20" and "test 21". To test the difference between them: 1. Import them into a mail folder 2. Select message "test 20" (it has longer headers than "test 21"). 3. Repeat the following: 4. { Click forward 5. Wait approx 3 seconds 6. Close it, answerind "Don't save" } 7. Until Mozilla crashes. In my case, 2 cycles were needed. 8. Select message "test 21" (it has shorter headers than "test 20"). 9. Do repeat the following: 10. { Click forward 11. Wait approx 3 seconds 12. Close it, answerind "Don't save" } 13. Until Mozilla crashes. In my case, 3 cycles were needed.

Hmm, I were wrong. Both messages cause a crash with roughly comparable numers of retries, only it is so erratic... Sometimes they crash after 2 cycles, sometimes after 3, sometimes even more... I give up. Any ideas?

The crashes do seem to be related to quoting headers in the new message, because I can't reproduce this when using "Edit Message As New" instead of "Forward". With "Edit Message As New", the headers aren't quoted and there's no crash (the JPEG image is dropped as usual, however.)

When you've crashed, did you send in a Talkback report? We can try to look up the stack trace to see where the crash occurs.

lchiang: yes, I did. Read comment #27 in this bug (I know it's long, but...) http://bugzilla.mozilla.org/show_bug.cgi?id=2903#c27

And another talkback on another trunk build (linux trunk build 2001121208): TB389572Z

This seems to be affected by the length of message headers, but bigger differences than 40 characters are required. The original message (attachment 61294 [details]) has several recipients listed in its headers and I only need one Forward/Close attempt to trigger a crash with it.

I also experience those crashes with latest win32 trunk builds (2001121203) on Windows 98. See those talkback reports: TB391082Q TB391239G

By the definitions on <http://bugzilla.mozilla.org/bug_status.html#severity> and <http://bugzilla.mozilla.org/enter_bug.cgi?format=guided>, crashing and dataloss bugs are of critical or possibly higher severity. Only changing open bugs to minimize unnecessary spam. Keywords to trigger this would be crash, topcrash, topcrash+, zt4newcrash, dataloss.

The original problem is not specific to Outlook Express messages, so I'm updating the summary. Any HTML message (including one composed by Mozilla) with an inline image will not include the image when forwarded-inline in the plain-text editor. (Inline forward in the HTML composer includes the entire message.) Note that displaying an HTML message with an inline image using View|Message Body As|PlainText causes the image to appear as an attachment. Forward Inline of a plaintext message with attachments carries those attachements along; therefore, it is reasonable to expect that the image be carried along on a plaintext forward of an HTML message, even tho that image cannot be inline in the plaintext message. Aleksander Adamowski, do you still see the crash situation you describe? I have tested using your attachment 61294 [details] (message of content-type=image/jpeg), and current Mozilla behaves without crashing, altho the image is not included in the forward. Assuming the crash situation does not still exist, this bug's severity should be downgraded (to normal, I'd say, as there are two possible workarounds: forward as attachment, or forward using the HTML editor). I don't know if it is possible in Mozilla to create a message with content-type=image/jpeg, I don't think so; that aspect seems like an edge case to me.

*** Bug 229802 has been marked as a duplicate of this bug. ***

*** Bug 231082 has been marked as a duplicate of this bug. ***

*** Bug 126562 has been marked as a duplicate of this bug. ***

For commercial use this is a very bad bug, because all office people want outlook back. We have to forward often mails with attachment and inline images and the office people hate mozilla only because of that bug. I hope it will be solved soon! And not in "Future", because that meens "Never", right? Please vote for it! What is needed for solving? More testcases?

Please solve problem in 1.7a! For all the people, that have to work with outlook-users and html-mails+attachment, daily many hours. Please tell us, what you need for solving!

1.) The image is not displayed inline 2.) Try to forward the mail in the folder, the image is missing in the composer

(dgolesny), we have plenty of test cases. What we don't have is someone willing, ready and able to do the work, at least not anytime in the immediate future. Ducarroz, should we put 'helpwanted' on this bug?

-> mscott for evaluation for SeaMonkey and Thunderbird. We have quite a few more recent duplicates so I'm assuming this is still a problem.

at least for this last example, the reason we fail to load the image is because the sending client is putting line breaks in the middle of the ID for the part: Content-Location: ATT-0-3BCA570E6E73E649A0C81562BE65FEEE-A TT558219.jpg and when the part is referenced there are no line returns in the middle of the string: IMG src="ATT-0-3BCA570E6E73E649A0C81562BE65FEEE-ATT558219.jpg" and that's why we don't load the image. 4.x has the same behavior.

Attachment 4755 [details], the first to this bug, exhibits the described problem without a split filename in the headers. The same problem exists for a message composed by Mozilla. I'd bet folding money the issue here is in the conversion of the HTML original to a plain-text new message while inlining. As in bug 187064, the embedded image is simply discarded with no regard as to whether it's a necessary part of the message. As in bug 212177, not even the 'alt' text for the image is preserved.

Hmm, I downloaded the first attachment in this thread which is an OE message with one inserted image. Copied it to Local Folders so I could treat it as a message. I then did a Forward/ As Inline and sent the message to myself. I received the message and was able to see the image inline. I know I'm configured to prefer HTML in my address book. So maybe Mike is right and this has nothing at all to do with messages from OE, but more with problems with us downconverting this particular example to plain text when we send it.

not going to hold the release for this. that's not to say that we wouldn't take a fix if one becomes available.

*** Bug 262270 has been marked as a duplicate of this bug. ***

*** Bug 274446 has been marked as a duplicate of this bug. ***

It'll be good to have some updated QA on this, whether it still occurs in SeaMonkey 2 Alphas or TB 3 Beta 1 -- I've been forwarding endless HTML messages with images though I might not be hitting this issue.

Gary, did you try the last testcase? Fails for me. Also, I think I saw some recently filed bugs on inline. I wonder if this shouldn't just be duped - I don't see it as a mime bug.

(In reply to comment #62) > Gary, did you try the last testcase? Fails for me. Also, I think I saw some > recently filed bugs on inline. I wonder if this shouldn't just be duped - I > don't see it as a mime bug. Nope, no idea. CC'ing bienvenu in the hope that he knows.

this is a mime multipart related message with a multipart alternative part along with the alternative parts, and then the .jpg file is the other related part. It doesn't shock me that mimedrft.cpp doesn't handle this correctly.

(In reply to comment #64) > this is a mime multipart related message with a multipart alternative part > along with the alternative parts, and then the .jpg file is the other related > part. It doesn't shock me that mimedrft.cpp doesn't handle this correctly. Is this bad? (Not that it blocks anything, since it's been around for so long)

it's worse now that forward inline is the default. It's not that rare a message structure.

(In reply to comment #61) > I've been forwarding endless HTML messages > with images though I might not be hitting this issue. At comment 46, I refocused this bug on the problem of inline-forwarding HTML with embedded images AS PLAIN. I'm no longer sure if that was completely correct, because comment 0 mentions a "broken image" link showing up in his email, implying reporter was forwarding as HTML; but I've never seen that symptom, and he seemed to be long gone by the time I got to this. Gary, I really don't know why there is any confusion on your part. Did you read this bug through? Do you know how to test this? Every one of the supplied testcases exhibit this problem, and you can easily reproduce it by creating any HTML message with an embedded image. (In reply to comment #64) > this is a mime multipart related message with a multipart alternative part > along with the alternative parts, and then the .jpg file is the other related > part. It doesn't shock me that mimedrft.cpp doesn't handle this correctly. The failure occurs for the simplest embedded image case: Content-Type: multipart/related part 1: text/html part 2: image/whatever And in re: comment 56, bug 212177 has been fixed and you will see the 'alt' text (assuming it exists) in the forwarded message text. See also bug 233412. Somewhere, there is a related bug, an RFE to make Forward Inline behave like Edit As New: if the message being forwarded is HTML, forward as HTML; if the message being forwarded is plain text, forward as plain.

(In reply to comment #67) > Gary, I really don't know why there is any confusion on your part. Did you > read this bug through? Do you know how to test this? Every one of the > supplied testcases exhibit this problem, and you can easily reproduce it by > creating any HTML message with an embedded image. I must have read when asleep. :-/ Yeah I sort-of see it now.

Comment on attachment 139648 [details] testcase: if you forward (inline) the attachment is missing This testcase is broken and unsuitable -> obsolete. broken: There's a linebreak character and a tab in content-location of the image which prevents the img from displaying in TB in message reader HTML: > <IMG src="ATT-0-3BCA570E6E73E649A0C81562BE65FEEE-ATT558219.jpg"> > Content-Location: ATT-0-3BCA570E6E73E649A0C81562BE65FEEE-A > TT558219.jpg After removing that linebreak, the msg displays correctly; in HTML mode, forwarding inline also works correctly incl. img. We only lose the image without warning when forwarding inline in plaintext mode (Shift+Forward). unsuitable: - empty plaintext part - HTML part without visible text (only &nbsp;) Parts which are there should have some content for testing purposes, empty parts will just be confusing and difficult to analyse.

Just noticed this behavior today, actually, with current release version of Thunderbird. Strangely, I came across this bug today also. Ended up sending an ascii email.

Removing myslef on all the bugs I'm cced on. Please NI me if you need something on MailNews Core bugs from me.

I know that people love to have some ancient bugs hang around the system forever. I prefer to close them if the problem no longer exists. The problem was described as: "Forward Inline (plain) fails on HTML msgs w/ inserted image" So a HTML or perhaps multipart message (plain+HTML) message doesn't get forwarded when the HTML part contains an embedded image. Well, why that might not have worked in 1999 it clearly works today and it is common practise. Also, I tried the test case from attachment 63280 [details] and it can be forwarded without any problem. I am closing this. Let's see, who complains.