Closed Bug 147645 Opened 23 years ago Closed 21 years ago

HTML compose: inline style not kept when edit as new/edit draft

Categories

(MailNews Core :: Composition, defect)

Product:
MailNews Core
Component:
Composition
Type:
defect
Priority:
Not set
Severity:
minor

Tracking

(Not tracked)

Status:
VERIFIED FIXED

People

(Reporter: fredrik.wendt, Assigned: bugzilla)

References

Details

From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.0+) Gecko/20020521 BuildID: 2002052121 When one selects "edit as new" from a draft, or any other mail for that matter, all inline style attributes are lost. Reproducible: Always Steps to Reproduce: 1. Start composing a new e-mail. 2. Choose Format -> Page colors and background 3. Click the Advanced Edit-button 4. Switch tab to Inline Style 5a. Enter property "font", value "12pt/1.4 sans-serif" 5b. Enter property "text-align", value "justify" 5c. Enter property "width", value "80ex" 5d. Enter property "margin", value "4em auto 2em" 5e. Enter property "background", value "url(http://www.linknet.se/img/logo_background.gif) #fff no-repeat fixed center" 6. Click OK button (Here's another bug, involving that the line-height of 1.4 is incorrectly translated to 1,4 which is incorrect, and leads to that the property is lost if not corrected manually.) 6,5 Enter Advanced Edit again, and change the value of property "line-height" to "1.4" (From here on, this could be done in two ways.) 7. Select Save as draft 8. Go to the Drafts folder where the letter was sent. 9. Select the letter, click the Edit draft-button (if visible) (Alternatively:) 7. Select Save as Template 8. Go to the templates folder where the letter was saved 9. Right-click the letter and select Edit as new Actual Results: The inline style properties that was entered is lost. Expected Results: The inline style properties remain intact. I'd like to have a template message which I can use for starting point for new e-mails. The company's style has to be manually reentered for every mail I send at current (font, margin, background). What I want is the ability to start editing a new e-mail with the inline style attributes of another e-mail. (I'm not requesting a fancy feature of templates.)
CAn you try this with a recent nightly? I've never actually used the "templates".. don't even know how.
I've stopped using Mozilla Mail because it was too memory consuming and slow for my taste. (Ximian Evolution (which is what I've transferred to) also easily syncs with my PDA.) The HTML-features though, sometimes makes me launch mozilla. I'll se if I can try this out with a newer nightly build.
Trying to duplicate this bug, using 1.7a. There is definitely something to this, but this area of the program is quite confusing. Reporter is correct that whatever the "current style" is for the <body> of an HTML message will override the style stored in a Draft, or using Edit as New on a Template (or on any other HTML message). "Current style" apparently defaults to only the fg/bg colors, font, and font-size as specified by Preferences|Mail&News|Composition. However, I am finding that any changes made in the compose window via Format|Page Colors and Background|Advanced Edit|Inline Style are applied not only in the message, but to subsequent messages. This style can be arbitrarily complex -- margins, borders, background-images, etc. In other words, if you set up the Inline Style the way you want it in the Advanced Edit page and click OK, that's how all the HTML messages will be formatted from then on, for some period of time. The style is global to all accounts. However, this "setting" does not persist over Mozilla sessions, so it cannot be used as the sort of style template desired by reporter. There are also certain other actions that can be taken that will reset the style, but I haven't figured out exactly what they are. The interaction between the Inline Style and the Composition preferences is inconsistent. - Text & background colors in Inline Style overrides the settings in Preferences. These fields are stored in the 'style' attribute, and also (for some reason) copied into the 'text' and 'bgcolor' attributes of <body>. The background color shown in the formatting toolbar follows the Prefs (unless changed), but whatever color is selected doesn't seem to be used for anything; no - Altho setting a font-size in the Inline Style causes that value to be stored in the 'style' attribute, the font size in Preferences (if not 'medium') overrides it. That's because the Pref's font-size is implemented via a <font> tag inside the body. - Setting the font-family in the Inline Style is mishandled entirely: the value is stored in the message as a 'font-family' attribute of <body> -- an *illegal* attribute that Mozilla doesn't support. (This is a separate bug.) So, whatever font is specified in Preferences always is used, even if it's just the default Variable Width font. Also: If an Inline Style is set with colors, as noted above, that causes the 'text' and 'bgcolor' attributes to be set to match. When the user returns to the Page Colors and Background dialog, these colors are shown as selected in the "Use custom colors" sample box. Choosing "Reader's default colors" and clicking OK, then returning to the Page Colors and Background dialog, shows the radio button set back to "Use custom colors." I'm guessing that a global style for {HTML Message Compose <body>} is created on startup, initialized by the Composition preferences; and that this style gets changed by the Advanced Edit|Inline Style dialog.
Status: UNCONFIRMED → NEW
Ever confirmed: true
OS: Linux → All
Hardware: PC → All
Summary: inline style not kept when edit as new → inline style not kept when edit as new/edit draft
(Following up on my comment 3) > - Setting the font-family in the Inline Style is mishandled entirely: the > value is stored in the message as a 'font-family' attribute of <body> -- an > *illegal* attribute that Mozilla doesn't support. (This is a separate bug.) Hmm. I have a message in my Drafts folder that exhibits this symptom, but I cannot duplicate this behavior at this time. The typical behavior seems to put the 'font-family' inside the 'style' attribute where it belongs; and if the Preferences does not specify a font-family, then the one from 'style' is used; otherwise, it is overridden by the Preferences' font included in the <font> tags. > Also: If an Inline Style is set with colors, as noted above, that causes the > 'text' and 'bgcolor' attributes to be set to match. When the user returns to > the Page Colors and Background dialog, these colors are shown as selected in > the "Use custom colors" sample box. Choosing "Reader's default colors" and > clicking OK, then returning to the Page Colors and Background dialog, shows > the radio button set back to "Use custom colors." I've opened bug 234252 for this issue.
Mike Cowperthwaite wrote: > > I'm guessing that a global style for {HTML Message Compose <body>} is created on > startup, initialized by the Composition preferences; and that this style gets > changed by the Advanced Edit|Inline Style dialog. hm, sounds very feasible. [please indulge posting fashion - i'm new to bugzilla] - i _suffer_ from this bug (want to have ci-template with inline-css) - want to point two things out: - this bug was filed ~600 days ago, by a curious coincidence the only reply apart from mine is from the day defore yesterday... - it took me three attempts and spoilt several hours to find that a filed bug of this concern actually exists (although knew of bugzilla!) - i can provide following additional observations: - choose "edit draft" of a (correctly displayed) html-mail containing inline-css. - "select all" > "insert>html..." shows this crippled code (excerpt, but note that the body tag is not shown!): <meta content="ext/html;charset=ISO-8859-15&quot;" http-equiv="ontent-Type&quot;"> <title></title> <span underline="" style=""></span> <table 552px="" height="" 840px="" style="" cellspacing=" border=" cellpadding="2"> __________________ -> is it possible that the transcoding of the html into the editable e-mail-format, is also faulty? a simply embedded jpg could also not be recovered from its cid-source (which doesn't work in some other situations as well) is it likely that anybody competent will fix that bug? how can i guess that? - i want to point out, that code generated by the mozilla MailNews lacks of elegance. this part of mozilla seems to me pretty underdeveloped yet. - and i wonder if Firefox is gonna evolve faster than mozilla herein. [OT] i'm certainly not the first who'S curious about a "strip"-function for attachmentz? i mean, this workaround via "edit as new" > "save in folder..." works, but tampers the sender-info. thank you for your time.
> I'm guessing that a global style for {HTML Message Compose <body>} is created > on startup, initialized by the Composition preferences; and that this style > gets changed by the Advanced Edit|Inline Style dialog. I've opened bug 234436 for this issue, which is different from the problem reported in this bug. I may be spinnig off one or two other observations from my comment 3 into separate bugs. Fredrik Wendt, sorry for all the distraction in your bug! Regarding the issue of this bug, see also bug 234354. Melchior Blausand, please note that "Bugzilla is not a discussion forum." Regarding your information: > - choose "edit draft" of a (correctly displayed) html-mail containing > inline-css. > - "select all" > "insert>html..." shows this crippled code (excerpt, but > note that the body tag is not shown!): > > <meta content="ext/html;charset=ISO-8859-15&quot;" > http-equiv="ontent-Type&quot;"> > <title></title> > <span underline="" style=""></span> > <table 552px="" height="" 840px="" style="" cellspacing=" border=" > cellpadding="2"> I tried reproducing this with a simple test, but did not get the corruption you are seeing. If you have a sample message that consistently gives these results, please open a new bug and include that message (in .EML format) as an attachment to the bug. > a "strip"-function for attachmentz? I assume you're referring to bug 2920, a very old bug indeed.
Summary: inline style not kept when edit as new/edit draft → HTML compose: inline style not kept when edit as new/edit draft
Melchior Blausand: see bug 142366 which describes a similar corruption of the HTML when an older message is loaded as a template, draft or Edit As New. All, xref bug 192557.
Fredrik Wendt, this bug appears to have been fixed in 1.8a -- perhaps as result of the fix to bug 192557. Can you confirm?
Mozilla is still loosing style properties when opening the "Advanced Property Editor" several times, specifically background-position (which is converted into -x-background-[x|y]-position). This bug seems to have been resolved, inline style is no longer lost when saving mail as draft or template. (I'm filing a new bug concerning the background-position property being lost after opening the APE multiple times.)
Status: NEW → RESOLVED
Closed: 21 years ago
Resolution: --- → FIXED
*** Bug 243172 has been marked as a duplicate of this bug. ***
Status: RESOLVED → VERIFIED
Product: MailNews → Core
Product: Core → MailNews Core
You need to log in before you can comment on or make changes to this bug.