User Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/27.0.1453.110 Safari/537.36 Steps to reproduce: I chose menu item "modify as new message" on a plain-text message. Note that if I html-compose a message without using decoration attributes, it will be sent at plain text *even if my setup is "html only"*. So such message can be the one I want to edit, for instance to add decorations (bold, italics, etc). Actual results: The compose window open in plain text mode. Expected results: The composition window should always open in html mode when the setup is "send html only". Or at least I shoud have the choice. For the moment, it is impossible to html-edit a text-mail... even if it was written in html-composer and encoded as text by thunderbird for some saving reason.

(In reply to fabrice.neyret from comment #0) > Note that if I html-compose a message without using decoration attributes, > it will be sent at plain text *even if my setup is "html only"*. It sounds for me that you are simply looking already known and frequently reported phenomena such as bug 136502, bug 414299, bug 584363 ...

Not quite, this is independent from the composition mode and auto-detect issue: > The compose window open in plain text mode. Either way, it's a duplicate.

There are similarities, but I don't think it is totally the same ! I listed several aspects: 1- At edit as new the compose window open in plain text mode 2- There are no alternate choice of mode, contrarily to write, reply, forward. This is thus not coherent. 3- Writing a message in html more generates a plain text message if I don't use decoration attributes. 4- Points 1 and 3 are incoherent: despite I only use html composer, if I want to re-edit my own message, I will no longer be allowed to used attributes decoration (bold, font size, etc). 5- Note that the display is different in the compose window and showing the corresponding draft (the less readable being the one in the compose window). Moreover, the "duplicate" you refer too is 12 years olds, so I feel it a bit like an implicit way of flagging my post as "won't be fixed". :-(

(In reply to fabrice.neyret from comment #3) > There are similarities, but I don't think it is totally the same ! It's a combination of several bugs on record already: > 1- At edit as new the compose window open in plain text mode Yes if that message has a text/plain part only, that's said bug 78794 and seemed to be your main point as emphasized in your report's summary. > 2- There are no alternate choice of mode, contrarily to write, reply, > forward. This is thus not coherent. That's again bug 78794, in combination with bug 216132. > 3- Writing a message in html more generates a plain text message if I don't > use decoration attributes. It's not generating any text/html part if auto-detect is used (the default) and no formatting applied that triggers sending of an HTML part. That's bug 136502 which also has a couple of workarounds listed. > 4- Points 1 and 3 are incoherent: despite I only use html composer, if I > want to re-edit my own message, I will no longer be allowed to used > attributes decoration (bold, font size, etc). That's again an issue with the auto-detect feature, thus bug 136502. > 5- Note that the display is different in the compose window and showing the > corresponding draft (the less readable being the one in the compose window). Saving a draft is not subject to auto-detection of formatting, thus is always saved in the mode the message was composed in. In contrast, Edit as New on a message you've sent which only has a plain-text part opens the composition window in plain-text mode per bug 78794. > Moreover, the "duplicate" you refer too is 12 years olds, so I feel it a bit > like an implicit way of flagging my post as "won't be fixed". :-( There is no use in keeping multiple bugs open on the same issue, thus distributing the discussion over multiple spots. There are many old bugs which are still pending and have been for years, which eventually get solved. If there was no intention to fix it, it would have been resolved as WONTFIX already (and there is no reason not to fix it other than nobody got around yet to look into it or the fix is more complex than anticipated).

> Moreover, the "duplicate" you refer too is 12 years olds, so I feel > it a bit like an implicit way of flagging my post as "won't be fixed". :-( As rsx11m says, "12 years old" is absolutely irelevant to duping process. As known by bug 731688 which is set in "Depends on:" field of bug 78794, (i) After open of bug 78794, Shift modifier was implemented for Compose menu, Reply menu etc. (ii) However, because of difference in internal implementation between Compose/Reply and "Edit As New", Shift modifier for Edit As New was not achieved by changes for (i). (iii) So, bug 731688 was opened. (iv) bug 731688 can resolve problem of bug 78794. Therefore, bug 731688 was set in Depends on: field of bug 78794. Your bug summary, which is "Abstract" of bug at B.M.O, is "modify as new message: wrong editing mode in compose window", and "one problem per a bug" is rule at B.M.O. Why can "close your bug as dup of bug 78794" be wrong? Please note that here is bugzilla.mozilla.org to report flaw in Tb's code to developers, not support or help forum.

Ok guys, thanks for your detailled explainations. Ok for stating "duplicate of various existing reports". Concerning the rule 1 bug 1 report: of course, but sometime I feel not so easy to decompose a given user experience into independant bugs. Plus sometimes it feels like describing the most possible symptoms of a same bug to help finding the cause). I'll try to improve it. -> In the present case I understand that all 5 items I listed are all known, so I don't need to extrat and repost any on them. Regards,

(In reply to fabrice.neyret from comment #6) > -> In the present case I understand that all 5 items I listed are all known, (snip) It looks for me "Biggest and most important problem you saw" is following. > 3- Writing a message in html more generates a plain text message if I don't use decoration attributes. How about change "bug summay"(=="Absctract" of bug at B.M.O") to it, and close this bug as dup of known bug for it? :-)

seems like I can't mark as duplicate of all 78794, 216132, 136502,731688 -> choose 1st.