From Bugzilla Helper: User-Agent: Mozilla/4.79 [en] (Windows NT 5.0; U) BuildID: 2002053012 I am using "Edit Message As New" menu function. It opens the "Compose" window with menu where there are no two menu bar items: "Insert" and "Format" Reproducible: Always Steps to Reproduce: 1. See above 2. 3.

Reporter: Have you installed Mozilla over an older build ? If yes do this : uninstall mozilla, delete all files in c:\programs\Mozilla.org\Mozilla\ (but save your plugins) and reinstall mozilla.

No, I have not got neither Mozilla nor Netscape (6.X, 7.0). So far I tested Mozilla under NT 4.0.

Just in case I chechek this bug under NU 4.0 (SP6a). The same result. And again I have there clean NEW install too.

ok. it took a while for me to figure this out. here are the variables: email type (plain text, html) user preference (plain text, html) my preference is plain text, so when I edit a plain text email as new, i get plain text composer, which is fine. (4) but if i edit an html message as new, i get the html editor. i didn't mind this, but it wasn't exactly expected either. (3) the reporter received a plain text email but his preference is html, so he expected to get the html editor. (1) the reporter probably is used to receiving html emails and editing them as new, in which case he'd get the html editor. (2) The reporter's issue is (1), my corollary is (3).

It looks like the Additional Comment #4 explains this bug correctly. But it is still the bug because 1. We do not have any indication what is type of the message (text/plain or text/html) in the mail center. In order to see it we need to view source. 2. We are using the existing message as the starting point on the new one and until the very end we do not know what will be the type of it (we can add some HTML things or not). So, we need to have it with ALL toolbars (or at least matches to the prefernces).

We should probably match the users Prefs (Compose msgs in html format, checked/unchecked) for this function.

that would be dataloss if a plaintext user edits an html email...

A question to Additional Comment #7 Why dataloss? HTML is "richer" than plain text. Am I right?

pay attention i'm a plain text user. suppose i select an html email and select edit message as new. if we follow my pref (plain text compose) per comment 6, then what we get is a text email which destroys whatever interesting html there was. I think we could probably do comment 6 w/ a prompt similar to composing in html and sending to a text recipient: This message was an html message, would you like to edit it as html or lose some formating and edit it as text?

I think the next from Additional Comment #9 is good: --------------------------- I think we could probably do comment 6 w/ a prompt similar to composing in html and sending to a text recipient: This message was an html message, would you like to edit it as html or lose some formating and edit it as text? --------------------------- With addition in case of plan text: --------------------------- This message is a plain text, would you like to edit it as HTML? --------------------------- (The last one I was expecting with the answer "yes").

Confirming as an enhancement, per discussion in February.

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

Bug 206460 mentions that this also occurs on the Macintosh. OS=All?

The end result of this bug would be covered by bug 140800 -- if you could switch between HTML and the (true) plain-text editor, it wouldn't matter which mode you opened the mail in.

*** This bug has been marked as a duplicate of 78794 ***