When replying to an e-mail where a background image was used, the reply should use that background image of the original message as its own background. In addition, any embedded pictures should also be included with the original message.

reporter, are you using recycle compose window? If so then this is a dup of bug 115855 Give more details like build id and steps to reproduce.

I am using build "Mozilla/5.0 (Macintosh; U; PPC; en-US; rv:0.9.7) Gecko/20011221". I will add four attachments showing screenshots of the issue. [OriginalMsg.jpg] -- The original message, sent using stationery in Outlook Express for Windows, is displayed in Mozilla. [ReplyInComposeWindow.jpg] -- The reply to the message, shown in the Compose window of Mozilla reached by clicking Reply on the toolbar. [ReplyAsReceived.jpg] -- The reply, sent from Mozilla, as displayed in Mozilla when the reply is received. [ReplyOE.jpg] -- The reply sent from Mozilla as displayed in the Macintosh version of Outlook Express, also noting that the original font "Trebuchet MS", which was used to compose the original message in OE for Windows, did not display in Mozilla at all but did display again in OE for Mac. Trebuchet MS is not the default font for HTML in either OE for Windows or for Mac so there really is a HTML tag specifying that font... which Mozilla did not read.

Confirming based on the screen shots attached by the reporter. We do have some known issues in displaying background color and images with mail messages in general. Nominating this bug. We should preserve the background color and images on mail messages. Reporter, Have you edited your pref.js file to include to use recycle compose window?

Not fixed yet in 0.9.8 -- does anyone know the target milestone on this bug?

No, I am not using Recycle Compose Window. All my settings in Mozilla are those set in the Edit>Preferences panel; I have not modified any .js files.

Any way this can make 0.9.9 or 1.0?

Why is this marked "nsbeta1-" in keywords? Can someone explain this?

I think this should be included in Mozilla 1.0 and the next releases of Netscape.

Changing OS and platform to All (from Macintosh and Mac System 9.x). Any explanation on why this has a nsbeta1- keyword?

It's not a trivial problem. The solution is not to set the body background image or colors as of the original message but rather to set the property of just the quoted text. I don't know if I'll have time to do that for 1.0

It would also be acceptable to let the background image of the original message be used as the background of the reply. In my opinion, this would be preferable.

Does the nsbeta- indicate this will not show up in any Netscape builds or just the next release?

it means it's unlikely it will make it for 1.0

Should I remove the 1.0 keyword? Is 1.1 or 1.2 a better milestone to enter?

One other issue I noticed that fixing this bug would also fix... If I click Reply to a message with a background that uses white text, the background doesn't show up (the reason for filing this bug). However, unless I change the color of the text in the outgoing message, it will be white. White on a white background means the recipient thinks I sent a blank e-mail.

May be dependant on bug 97092 (Compose HTML mail WYSIWYG). Without 97092 fixed then the background (and other components of the rich HTML message) may not display correctly in the compose window.

Using "Edit Message as New" preserves the background image. If there was some way to copy some of the code used to generate the Edit Message as New window then fixing this bug would be easier. Also, most e-mail backgrounds are actually tiled small images.

Another comment on this bug... I get a good deal of e-mail from people who use background images in e-mail. Sometimes when they use light-colored text it doesn't show up well on a white background when I reply (since the background isn't preserved). Other times my message is indented heavily for no apparent reason (because the stationery file the sender used had a wide left banner). Preserving the background would make my replies look MUCH better. Wouldn't this be as simple as programming the Reply button to check for a background on the original message, and if present, save it to the user's system TEMP folder, then apply that image to the new message as its background image? Or would it not be that simple to program that procedure? I'm looking forward to 1.2 alpha!

Add some code to the process that occurs when Reply is clicked: Click Reply Check message source for background images 1. Is message text/plain? If Y, create compose window. If N, continue... 2. Are user's preferences set to compose mail plain text? If N, continue, if Y, draw plain text compose window. 3. Is there a background color (e.g. bgColor=3D#000000) 4. Is there a background picture or stationery? <BODY style=3D"BACKGROUND-REPEAT: repeat-y" text=3D#ff8080 = bgColor=3D#000000=20 leftMargin=3D110 = background=3Dcid:004401c2290a$832a8990$010432d1@computer> If Yes to 3, prepare to apply background color to message. If Yes to 4, save background image to temp folder. If Yes to either 3 or 4, display dialog "Do you want to apply background from original message to your reply?" Yes No (also available as an option in Preferences "Preserve background in replies"). If No is clicked, create compose window. If Yes is clicked, apply background color to message and use image saved to Temp as background for new message. ** If no temp folder exists then create Temp folder in Mozilla subdirectory or in browser cache **

Background colors aren't preserved either. Still on target for 1.2? <<revised summary>>

1.2 alpha freeze date is very soon -- need to either land this patch or else postpone to 1.2 beta or later.

Marking as "4xp" because Communicator 4.8 has this feature. Target milestone changed to 1.2 beta; can we get this accepted for Netscape (nsbeta1+) and landed for 1.2 beta or 1.2 final?

Joel - you shouldn't change target milestone or priority unless you are the owner of the bug, even if you think they're wrong. those settings are for the owner to prioritise their work - you don't get to decide what people are working on (unless you're employing them...)

Goodness me, no. If someone is crass enough to send me some coloured, styled, bloated, fontified rubbish purporting to be an email (it's about the information content, people), I definitely don't want my reply to them to be similarly infected. Just my view. And no, I don't have time to hang around in this bug and argue about it. :-) Gerv

Sorry to say this, but this is probably the most desperate bug report I have ever seen. There are 22 comments from the reporter himself, ouf ot a total of 28 comments! That's pretty amazing. Comment 22: > Wouldn't this be as simple as programming the Reply button to check for > a background on the original message, and if present, save it to the > user's system TEMP folder, then apply that image to the new message as > its background image? Maybe. Why don't you try it yourself? ;) > I'm looking forward to 1.2 alpha! It's already out! Enjoy! In comment 25 you talk about landing "this patch". What patch? I don't see a patch in the attachment list. If you have a patch waiting for review, then please attach it to the bug report. Or are you waiting for someone else to fix this bug for you? Also, as Michael pointed out, you should never change the target milestone unless you are the assignee to this bug. Gerv says he wouldn't want this to be fixed. That's his strong opinion, but I think many people will agree that this is not an important bug to fix, which is why no one have fixed it yet. Complaining about it won't make the volunteers work faster. Just my two cents.

In reply to Comment #29 -- Many apologies. I would hope that it would be fixed at some time but will let the programmers determine the schedule. No more bug spamming. ;-) -Joel

Mail triage team: nsbeta1-

This "feature" would not likely be used at all in business/corporate settings and when added should have an option to be disabled. On the other hand, when communicating with family/friends this might have a place. I would be for adding this but making it an option to disable the feature. This could be done just as in 4.7x with the addition of the preference to disable rich-content replies.

Switching RFE to Thunderbird Best as extension rather than in program code (to reduce bloat)

Per reporter's comment 33, changing this to an enhancement request. Moving to Core -- a fix for this would by default be part of both TB and the suite. See also bug 204974, which is about preserving original message's font in a reply.

I'd like to add my comments to this bug. Using Thunderbird 1.5. I received an HTML message which has a background image - it was specified something like this (using brackets just to make sure this doesn't format as HTML): [head] [style] body { background-image:url('http://www.domain.com/myimage.gif'); } [/style] [/head] When I did a reply/forward, my message composition window kept the background image, but as soon as it was sent, it lost it (confirmed by viewing the message in my Sent Items folder). When I did a Message Source on the Sent Items message, the code looked more like this: [head] [style] body { background-image: url('<a class="moz-txt-link-freetext" href="http://www.domain.com/myimage.gif">http://www.domain.com/myimage.gif</a>'); } [/style] [/head] So, it seems that Thunderbird is processing the "http" text as a link, which is incorrect in this case. If you can just fix that, that should solve my problem of why the background image isn't showing up.

One more thing - keeping the background image as part of the reply is how Outlook works, and not that Thunderbird has to be exactly like Outlook, but for those who design HTML emails (like me), it would be nice for them to be compatible with something like this. Thanks.