Closed Bug 294793 Opened 20 years ago Closed 20 years ago

Using a template changes mail composer's default background color

Categories

(MailNews Core :: Composition, defect)

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

Tracking

(Not tracked)

Status:
VERIFIED FIXED

People

(Reporter: bugzilla2, Assigned: neil)

References

Details

(Keywords: fixed1.8.1)

Attachments

(1 file, 1 obsolete file)

Fixed diff
2.68 KB, patch
dmosedale
: superreview+
mscott
: approval-branch-1.8.1+
Details | Diff | Splinter Review
User-Agent: Mozilla/5.0 (Windows; U; Win 9x 4.90; en-US; rv:1.8b2) Gecko/20050511 Build Identifier: Mozilla/5.0 (Windows; U; Win 9x 4.90; en-US; rv:1.8b2) Gecko/20050511 When I open a template with a background color, that color becomes the default for all messages. The background color cannot be changed back with the background color picker. Reproducible: Always Steps to Reproduce: 1. Open the "American Greetings: Flowers template in Local Folders/Templates 2. Note its cyan background color 3. Close the compose window 4. Open a new compose window by clicking on the compose toolbar button 5, Note the default compose now has a cyan background 6. Try to change the background color back Actual Results: Merely opening the template has set the default background color for all messages Expected Results: Templates should not change the default compose settings for messages not composed with them. The only way I seem to be able to change it back is to select another template that has a white or no background color.
sounds like a bug in cached composer.
Assignee: composer → nobody
Component: Composer → MailNews: Composition
Product: Mozilla Application Suite → Core
Summary: Using a template changes mail composer's default background color → Using a template changes mail composer's default background color
Version: unspecified → Trunk
(In reply to comment #1) > sounds like a bug in cached composer. This is true, and easy to test: after opening a compose window that shows the unwanted background, open *another* HTML compose window: background is set per the preference, not the template. A very similar symptom for forward-inlining was fixed at bug 249882, altho I'm currenty not seeing background colors carried forward into forwarded-inline mail. I'm not seeing this bug's symptom after opening a draft, only with a template or Edit As New. I see it in TB 1.5b2 and TB 1.6a1.
OS: Windows ME → All
Hardware: PC → All
Attached patch Proposed patch (obsolete) — — Splinter Review
Well it was fairly obvious that nobody was clearing the attributes on the body element correctly. Firstly I thought the problem was the ConvertAndLoadComposeWindow was over-optimizing for an empty body, then I thought that CloseWindow needed to clear the existing document more thoroughly, but both of those ideas fell foul of the problem that RebuildDocumentFromSource doesn't clear the body attributes if it doesn't find the <body> tag. Simply calling RebuildDocumentFromSource(NS_LITERAL_STRING("<body>")) from CloseWindow probably works around the problem but I went for a complete patch.
Assignee: nobody → neil.parkwaycc.co.uk
Status: NEW → ASSIGNED
Attachment #200900 - Flags: superreview?(mscott)
Attachment #200900 - Flags: review?(daniel)
Attachment #200900 - Flags: review?(daniel) → review?(brade)
Attachment #200900 - Flags: review?(brade) → review+
Attached patch Fixed diff — — Splinter Review
As dmose kindly pointed out an error in the creation of the patch ;-)
Attachment #200900 - Attachment is obsolete: true
Attachment #201701 - Flags: superreview?(dmose)
Attachment #200900 - Flags: superreview?(mscott)
Comment on attachment 201701 [details] [diff] [review] Fixed diff >Index: editor/libeditor/html/nsHTMLEditor.cpp >=================================================================== >RCS file: /cvsroot/mozilla/editor/libeditor/html/nsHTMLEditor.cpp,v >retrieving revision 1.532 >diff -p -u -d -r1.532 nsHTMLEditor.cpp >--- editor/libeditor/html/nsHTMLEditor.cpp 12 Sep 2005 18:41:13 -0000 1.532 >+++ editor/libeditor/html/nsHTMLEditor.cpp 3 Nov 2005 00:27:12 -0000 >@@ -1797,6 +1797,13 @@ nsHTMLEditor::RebuildDocumentFromSource( > res = LoadHTML(body + aSourceString); > if (NS_FAILED(res)) return res; > >+ nsCOMPtr<nsIDOMElement> divElement; >+ res = CreateElementWithDefaults(NS_LITERAL_STRING("div"), getter_AddRefs(divElement)); >+ if (NS_FAILED(res)) return res; >+ >+ res = CloneAttributes(bodyElement, divElement); >+ if (NS_FAILED(res)) return res; >+ I can see that the above was done in order to match prevailing style, but this particular style has a serious debugging issue: it's not possible set a breakpoint on any of those return statements. So I'd like to request that you put each return statement on its own line. sr=dmose with that change
Attachment #201701 - Flags: superreview?(dmose) → superreview+
Fix checked in.
Status: ASSIGNED → RESOLVED
Closed: 20 years ago
Resolution: --- → FIXED
V with TB 1.6a1-1201 Thanks, Neil!
Status: RESOLVED → VERIFIED
*** Bug 324175 has been marked as a duplicate of this bug. ***
howdy y'all, please excuse my ignorance, but i can't tell if this will be/has been applied to the branch[es]. would someone enlighten me on this? plus, please point out the correct way to ... - ask this kind of question - figure it out myself next time take care, lee
Attachment #201701 - Flags: approval-branch-1.8.1?(mscott)
Attachment #201701 - Flags: approval-branch-1.8.1?(mscott) → approval-branch-1.8.1+
(In reply to comment #9) >please excuse my ignorance, but i can't tell if this will be/has been applied >to the branch[es]. would someone enlighten me on this? Look for the approval1.8.1 flag and fixed1.8.1 keyword ;-)
Keywords: fixed1.8.1
*** Bug 343637 has been marked as a duplicate of this bug. ***
*** Bug 342562 has been marked as a duplicate of this bug. ***
Product: Core → MailNews Core
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: