Edit Draft message brings up composition window with wrong background color and lost HTML formatting

RESOLVED WORKSFORME

Status

SeaMonkey
MailNews: Composition
RESOLVED WORKSFORME
9 years ago
9 years ago

People

(Reporter: u331436, Unassigned)

Tracking

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment)

(Reporter)

Description

9 years ago
User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1b2pre) Gecko/20081122 SeaMonkey/2.0a2pre
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1b2pre) Gecko/20081122 SeaMonkey/2.0a2pre

I confirmed the same problem on Linux and WinXP platforms.
When editing in HTML a message in the draft folder (IMAP account) the composition window comes up with blue background and lost HTML formatting.
This is very close to TB bug 457182 and bug 392558
The problem affects nightly builds (2.0a2pre), starting around the Nov 17th or 18th nightly build.
Some of the formatting is not not lost (for instance my Email signature is partially modified with spaces replaced by "&= amp;=3D nbsp;" but the mailto stays fine..
I tested the "Edit Draft" on a POP account and the problem do not show.
(note: as a tester, it is the first bug I file, please be kind to a newbie !!)


Reproducible: Always

Steps to Reproduce:
1.Save any message in the draft folder (IMAP account)
2.Edit Draft 
3.Editing window shows modified background and lost HTML formatting
(related to IMAP account, not POP. 
Could not reproduce on local folders.
Actual Results:  
Background color changed,
Fonts changed
HTML lost (tables, spaces, etc..)
Some HTML kept (mailto, for instance)

Expected Results:  
Editing window showing the same aspect as when viewing the message in the draft folder.

seems close to bug 457182 and bug 392558 (Thunderbird)
Dominique, please change Component to MailNews: Composition. Composer is for the stand-alone HTML creation part of the suite. While you're at it, also change Version to Trunk please. Since you confirmed the issue on both Linux and Windows, also change Platform to All.

I tried to reproduce your problem with [1] but somehow I failed to do so. Since your step 1 isn't very precise please attach the source code of a message that triggers the problem for you here (use Ctrl+U in the window showing the Edit Draft button).

[1] Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1b2pre) Gecko/20081119 SeaMonkey/2.0a2pre

Updated

9 years ago
Component: Composer → MailNews: Composition
OS: Linux → All
QA Contact: composer → mailnews-composition
Version: unspecified → Trunk
(Reporter)

Comment 2

9 years ago
Created attachment 349655 [details]
message showing the problem (with signature certificate)

I find the problem with the example test message attached

However, I tested without my signature certificate, and all works fine !!!
The problem is brought by the attached certificate
I tested only the winXP version with and without the signature certificate.
(Reporter)

Comment 3

9 years ago
Steps to Reproduce (more details):
1.Create and save an Email message in the draft folder (IMAP account), digitally signed (personal certificate)
2.Edit Draft: Edit the saved draft message 
3.Editing window shows modified background color and lost HTML formatting: wrong font, wrong font size, bold or underline lost, etc...

Comment 4

9 years ago
If you see this problem with a 2008-11-12 build but not in 2008-11-11, this
may be another signature-related regression from the fix for bug 307023.
See bug 464969 for a similar issue.

Comment 5

9 years ago
Make that bug 464993 rather (change of background color), but related.
(Reporter)

Comment 6

9 years ago
SM2.02apre on Nov 27th, 2008 (Build ID: 20081127001322) solves the problem.
changing the status to resolved.
Status: UNCONFIRMED → RESOLVED
Last Resolved: 9 years ago
Resolution: --- → FIXED

Comment 7

9 years ago
In this Bug not set to solve this problem.

Change Status from FIXED to WFM.
Resolution: FIXED → WORKSFORME
Just for the record: The reason why this is fixed is most probably given in bug 464969 comment 14 (the fix for bug 307023 was backed out).

Comment 9

9 years ago
Yes to comment #8, the problem usually being whether to resolve cases where no actual fix was checked in for the bug itself as FIXED or WFM. I'd tend to "WFM" to make that distinction, as there is no specific "BY" resolution available.
(Reporter)

Comment 10

9 years ago
Good point. Thanks for the patient education of a newbie.
You need to log in before you can comment on or make changes to this bug.