Build ID: 2001050204 Reproducible: Frequesntly Steps: 1. Install Build ID: 2001050304 2. Launch the browser 3. Open Mail window 4. Edit a sent message as new (Ctrl +E) Results: Message Compose HTML toolbar is not displayed. I can't edit a message and add "smiley faces".

Marking this one as nsbeta1 to get it on the radar. Adding jenm.

This is the way we did it in 4.x - it's specific to plaintext only. Editing a plaintext message as new allows you to edit it in plaintext mode. Doinf things like converting a plaintext message to html would get you where you want to be, but as this bug stands, it should be an RFE, and needs to be futured.

adding the nsbeta1-

This problem still exists as of branch build 0.9.2 -2001-07-27-00 When you select a message from a pop account inbox and click on edit as new message from context menu or from file menu item it does not show the html toolbar and appear like a plain text compose even though html compose is selected in accounts and settings for that account.

I'm still not convinced we need to fix this. Converting a plaintext message to HTML is I believe what jaime is requesting, but I would need to see what the purists think to be convinced that this is something we should do.

I do not know if this is relevant or not, but I have experienced a somewhat similar problem with yesterday's build. Build ID: 2001112808 Reproducible: Inconsistant and Infrequent Steps: 1. Install Build ID: 2001112808 2. Launch the browser 3. Open New Message window Results: Message Compose HTML toolbar is not displayed. I can't edit a message and add "smiley faces". (lazy me just cut and paste and edited Jaime's original comments) I can not seem to reproduce the problem at will, but it has happenned several times today. Once it does it once, it continues to do it until I restart Mozilla. I have not seen this happen previously. Is there any reason why it might be randomly assumming that I am doing a plain text message?

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

Well, this option is also missing when a mailto: link is clicked on a web page. Plain text is automatically assumed and it cannot be changed. Even if I happen to know that the individual who's address is on the page, I cannot change it. Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.4b) Gecko/20030507

Using "Edit as New" is basically the same as opening a template (see the patch submitted for bug 91937). So, the format in which the message was originally composed is what applies. If you "Edit as New" on a message that was originally HTML, it will open into the HTML compose window -- even if the account is set for plain text. This behavior seems correct to me, and I'm inclined to agree with K.Murray's comment 5. Jaime Rodriguez, do you want to maintain as an enhancement request, or resolve it as WorksForMe? Cedric Sullivan's comment 8 doesn't really pertain to this bug; however, I don't see that it's correct, either: a mailto: link from a web page (or elsewhere) opens a compose window "from" the default account, and the HTML compose preference for that account is utilized. Mark Bitterling's comment 6 does not pertain to this bug either, and if that behavior did exist in a particular build, it has long been fixed.

See also bug 140800.

My comment 6 may not pertain to this bug, but the behavior most certainly did exist. I know that it still existed in builds from November 2003. I do not know if it has been fixed since then or not because in I have given up using Mozilla mail.

Bug still present in Mozilla 1.6. To convince K.Murray (comment 5): when I reply to a text-only message, the formatting is enabled. (Shift-click disables formatting). On the other hand, when I edit as new a text-only messsage, the formatting is disabled (shift-click doesn't work). In both cases, I want to modify the message, and the formatting is one thing I could want to change (bold text, table, ...). Why should there be a difference ? Btw shift-click was suggested in bug 140800.

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

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

Using Thunderbird 1.5 Beta 2 I have two mail-accounts. My default mail account A is set to text mails only. The other account B is set to html mail. If I open the compose window then account A is selected and no html toolbar is displayed as expected. Now if I select account B in the "from" combobox I couldn't write html mails. No html toolbar is displayed and the text isn't formated as html. :-(

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

i made a duplicate of this bug (sorry, i really checked before), and it's not correct that you get plaintext editing only if the message was plain text. see my bug #323149. the point is that my thunderbird is setup to always, always send HTML and plain text (both). default configuration. but thunderbird "optimizes" the mail. if, with such a setup, you write in your message only "plain text" (no bold, italics, images pasted etc), thunderbird sees that for that mail plain text == HTML and optimizes the mail => only sends plain text. and when you edit that mail, you are unable to edit it with HTML tags (which you could when you originally wrote the mail). in such a form (and it's like that with 1.5), it will be hit with the default configuration with thunderbird and in my opinion this bug shouldn't be marked as enhancement but as "bug". see my bug for 3-step reproduction with thunderbird's default settings.

btw, that makes thunderbird's behaviour seem random. when doing "edit a new" sometimes you get the HTML bar (when the mail had HTML tags in it), sometimes not. it's quite confusing and it was bothering me for a long time before i took the time to understand when it's showing the HTML bar and when it's not.

What you seem to be saying is that, since you composed it in HTML originally, you should be able to get HTML again with Edit As New. Unfortunately, the original HTML information is gone; the copy in your Sent folder is a plain-text message. (In reply to comment #17) > if [...] you write in your message only "plain text" (no bold, italics, > images pasted etc), thunderbird sees that for that mail plain text == > HTML and optimizes the mail => only sends plain text. That's bug 157346. Incidentally, an image in the message is *not* considered "formatting" and the mail will be sent as plain, dropping the image entirely; this is bug 180997. There are two ways to bypass the optimization: ensure that every recipient of the message is listed in the address book as "prefers to receive HTML"; or, with every composition, select: Options | Format | Plain & Rich Bug 136502 was opened to request a way not to have jump thru these hoops.

(In reply to comment #19) > What you seem to be saying is that, since you composed it in HTML originally, > you should be able to get HTML again with Edit As New. Unfortunately, the > original HTML information is gone; the copy in your Sent folder is a plain-text > message. yes, that's what i meant. most "newbie" users are very confused by this. where are my bold/italics etc buttons gone? how come i can't paste images anymore? those users changed nothing to thunderbird settings. this is default config. they shouldn't have to know the difference between plaintext and HTML composing. please, requalify this bug as "normal". it's not an enhancement that people are requesting, it's a bug fix IMHO. otherwise technically i see no problem converting plaintext to html. it's just escaping some characters and adding <br>s, doesn't thunderbird have that code somewhere already?

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

I agree with comment 20 that this is a bug that needs fixing. Either the formatting toolbar should always be there in the compose window, or there should be an easy and intuitive way to get it back when it's missing. (FWIW, I first looked at the buttons bar for an "HTML" button, then in View->Toolbars to see if I could re-enable the formatting toolbar there.)

OK -- So when is this going to finally get fixed? It is January 23, 2009 at 13:30 EST and this bug was originally opened May 3, 2001 at 15:39 PST - so its almost 8 years old I am on Thunderbird 2.0.0.19 (20081209) and this still has yet to be fixed. I have my default in my account options to compose in HTML So every email I compose - whether a completely new email or done as an Edit As New. should be an HTML email. Thank you Julia

Suggestion- When editing a 'plain text' message why not have a single button in place of the HTML toolbar that says [Convert to HTML]. This is the simplest and most user friendly cure to the problem- at least for the user. I appreciate it might not be the simplest for the programmer.

(In reply to comment #26) > Suggestion- When editing a 'plain text' message why not have a single button in > place of the HTML toolbar that says [Convert to HTML]. This is the simplest and > most user friendly cure to the problem- at least for the user. I appreciate it > might not be the simplest for the programmer. I agree that things need to be clear for the user. I am still not certain what Emmanuel Touzery comment 18 means when he says he understands 'when it's showing the HTML bar and when it's not'. Does it mean that if you format a single piece of text, say by putting it in bold that if you later 'Edit As New' the email will have formatting available? I also agree with Emmanuelthat if you need to re-edit an email, you proabably need to be able to format in bold or italic to highlight changes. Bug or not, it is a need-to-fix and not an enghancement. Thanks Hugh Manzu

(In reply to comment #26) > Suggestion- When editing a 'plain text' message why not have a single button in > place of the HTML toolbar that says [Convert to HTML]. This is the simplest and > most user friendly cure to the problem- at least for the user. I appreciate it > might not be the simplest for the programmer. that's bug 140800

So what is happening with this? The last message was over 2 years ago and the bug still exists in Thunderbird 10.0.2!

STR of comment 0 and current summary are not accurate (I've fixed the summary). Actual Results and Expected Results are incomplete/missing. Bugs with insufficient description that doesn't follow the prescribed format are unlikely to receive attention and cannot be fixed. MSP, you might want to help move this bug forward by providing better description in note form with concise STR, Actual Results, and Expected Results. Then you'll probably find that this bug is just the general symptom of some other bugs, some of which have already been filed and mentioned here. I'll try to file the missing pieces and report back here. Ping me if I don't.

See Bug 672475 Comment 7 for an overview of current behaviour and outstanding bugs.

FTR: For *HTML messages* > Edit as new - Shift modifier key does not work anywhere (morph this bug, or better: new bug; I'll do that soon) - at first sight, there seems to be a workaround to toggle the format from *within* composition, using Options > Format > Plain text only. But it doesn't seem to work very well, HTML format is not stripped. I think I've seen some bugs that partially cover this, namely that handling inline pictures when converting HTML to plain text is broken.

@Thomas D. No need. See Jaime Rodriguez, Jr. original description of the bug on 2001-05-03 15:39:00 PDT. Thunderbird 10.0.2 still behaves in exactly the same way. I'll come back in another decade or so to see if anything has happened:-) As an end user, my suggestion is get rid of plain text mode altogether. It is difficult to believe many people, apart from some who post here, ever use it these days. At the very least make it invisible in the UI and optimise transmission into plain text if there is no HTML formatting, but frankly even that seems like a waste of effort. Network bandwidth for email is hardly an issue these days. Almost everyone has broadband.

(In reply to MSP from comment #35) MSP, thanks for quick reply. As you are still new to Bugzilla, allow me to help a little. > @Thomas D. > No need. Pls mention the comment you are responding to, and cite a line or two so that other people can see what you are talking about, like this (use reply button on top of comment u r responding to, and remove irrelevant parts of the quote): (In reply to Thomas D. from comment #32) > Bugs with insufficient description that doesn't follow the prescribed format > are unlikely to receive attention and cannot be fixed. > MSP, you might want to help move this bug forward by providing better > description in note form with concise STR, Actual Results, and Expected > Results. So to this one, MSP replies in comment 35: > No need. > See Jaime Rodriguez, Jr. original description of the bug on > 2001-05-03 15:39:00 PDT. Thunderbird 10.0.2 still behaves in exactly the > same way. As I stated in comment 35, the original description is not sufficient (i.e. lacking relevant information) and does not follow the required format. A problem or RFE that cannot be fully understood cannot be fixed, so the bad description is *one* reason why this has not received attention for many years. Believe me, after many years of triaging BMO bugs, I know what I am talking about. So if you are still interested in improving the behaviour, there *is* a need for a new description. Some hints: - comment 0 doesn't state what kind of message is edited as new (plain txt vs. HTML). That's *very* relevant for the issue at hand - comment 0 doesn't mention the state of any of the relevant settings (e.g. Tools > Options > Composition > Send Options > Text format), again crucial for understanding the behaviour - Actual results are not in note form, and they are inaccurate, because of inaccurate STR: * for HTML messages that are edited as new, we *do* show format toolbar (i.e. use HTML format for new msg); and the UI allows reverting them into plain text, although it doesn't seem to work well (which is another bug). * so it's only for plain-text msgs that there is *no* way to toggle the new msg to HTML format. - Expected results are missing entirely. There might be good reasons why editing a plain text msg as new will limit the format to plain text; if you think otherwise, you need to state why and provide details of the new behaviour that you are advocating for, for all the different scenarios outlined in the actual behaviour. - format and style matters: descriptions/comments in note form (short & concise, but as detailed as necessary) are easier to understand, and they help to focus on the relevant points (I admit it's not easy sometimes, even for myself ;) > I'll come back in another decade or so to see if anything has happened:-) It also depends on you ;) Since TB is open source and freeware, officially there are no obligations, and you are most welcome to contribute... If you can't code, help clarify the bug to an extent that we can offer a detailed proposal for changing the existing behaviour, which can be ui-reviewed by devs. Back to square one: Better description needed ;) > As an end user, my suggestion is get rid of plain text mode altogether. It > is difficult to believe many people, apart from some who post here, ever use > it these days. At the very least make it invisible in the UI and optimise > transmission into plain text if there is no HTML formatting, but frankly > even that seems like a waste of effort. Network bandwidth for email is > hardly an issue these days. Almost everyone has broadband. Well, I've just returned from Africa and almost *no one* has broadband (but internet and mail are relatively frequent, mail even on simple mobile phones). So we shouldn't rush to conclusions from our own POV: For a product used worldwide, we cannot simply abandon plain text format. But I agree that most people are likely to live in *either* world, with *or* without broadband, so they'll either use plain text always *or* HTML always. So *toggling* the format is certainly less relevant than before.

Bug 731688 fixes part of this problem, but it isn't a duplicate (as explained in bug 731688 comment 0). With respect to this bug, I find it suprising that when replying or forwarding a plaintext msg, HTML format is default, but for "edit as new" of plaintext msg, we take over plaintext from original msg to new msg. Especially with Auto-Format when sending (which I think will use plain text when there is no formatting), I don't see any harm editing plaintext msg as HTML. Maybe that's similar to bug 136502.

Notwithstanding the bad shape of this bug (see comment 36), and it's symptomatic nature (most causes/fixes covered in other bugs), I believe this needs to be classified as a bug from an UX perspective, as requested by several previous commenters, and also in view of 11 duplicates currently. ux-control: users don't feel in control because even when they set all possible settings to prefer HTML, this bug will still occur. Worse, due to the wrong design around Format > Auto-Detect (e.g. forced on everybody: bug 136502; too aggressive: Bug 584363 Comment 16; dataloss: Bug 414299 Comment 108), users who have or want nothing to do with plaintext can easily run into this bug: First, we forcibly downgrade their HTML compositions to plaintext without users' consent. Thus sent msg gets saved by TB as plaintext, although originally composed as HTML. "Edit as new" on such sent msg then forces plaintext editing with no way out (this bug), short of using all sorts of weird workarounds. ux-efficiency: obviously, possible workarounds like using reply, forward, or copy and paste into HTML composition are violating ux-efficiency to the point of ux-interruption. ux-consistency: We should examine the general design currently defined by complex interaction of various settings: per-account-HTML composition, per-message-Format-Auto-Detect, per-address-Prefers-HTML-determination etc... As I explained elsewhere, while all of these certainly have their historical reasons, their interaction is no longer transparent enough, and wrongly based on outdated assumptions about users' preference for plaintext. There's evidence on a lot of bugs that users (even devs) have little knowledge about those settings, much less their interaction, but users are expecting ux-wysiwyg in a more message-centric perspective: You either have a general preference for composing in plaintext, or you don't. For those who don't, it comes as a surprise that while for a given plaintext msg, Reply and Forward will open HTML composition, only "Edit as New" behaves differently and forces plaintext (hence ux-consistency). For such users, "Edit as New" is just another way of starting a new msg in their preferred format (HTML). Imo that's not the same thing as using templates from templates folder, where templates having plaintext can be assumed a deliberate choice of format. ux-trust: Wrong design wrt such basic operations as composing in users' preferred format can easily have a negative impact on users' trust of our product.

I realise that comments from mere users are not particularly welcome here:-)... However, in case anyone is interested, I have just found what appears to a simple workaround for this problem. I had cause to add a signature text containing HTML to all outgoing messages. Following this, I noticed that "the problem" (in the interests of brevity, I assume by this time that we do all know what we are talking about now) has gone away. My guess is that the HTML in the signature prevents messages not containing any formatting from being "optimised" into plain text. I haven't tried it, but for those who do not actually require a signature text and do not mind all their messages being sent in HTML, it may be that a blank section of HTML in the signature text would work just as well, e.g. an empty span or an empty div.

Man, you are genious ! and it even work using a void html comment <!----> (while <b></b> was wiped out).

My only concern with using some "blank" HTML would be that someone might decide to "improve" the "optimisation" to convert HTML that doesn't render anything into plain text:-)

well, seeing the horrible html soup generated after basic editing in the composer (the main cause of various copy-paste-delete bugs by itself, I guess), I think there are many things to "optimize" before reaching the point to try to detect and delete blanck html... :-/

@MSP Could you please provide the complete content of the "dummy/empty" signature-trick ? I've been trying several combinations and don't get the expected result :-( Thanks

Hi wquatan, As I said originally, I'm not actually using a "dummy empty" signature, but fabrice indicated that an empty HTML comment works. My signature text happens to be the following:- <hr/><br/><a href="http://populationmatters.org">populationmatters.org</a> This is placed in the "signature text box" on the main account settings page. You also need to remember to check the "Use HTML" box. I guess fabrice did the same thing but put <!----> in the signature box instead, i.e. an empty HTML comment.

Well, adding a html signature <!----> to your outgoing messages will help when you edit those messages as new, but when you edit an old or incoming message as new it won't containt the html signature, so you'll still get the plain text editor.

Ok, thank you all ! It's working now for the messages in my Sent Items, just what I needed. Seems to be an issue which is around since long, can't imagine why it's still not solved in TB

TB 38. Issue still there...

TB 40.0 on September 7, 2015! Why is this awful bug still not solved!

Indeed. This continues to be a pain in my operations.

Same here. Very annoying. I would thinkg it would be relatively easy to fit this functionality into the one used for new messages...

Please allow editing that message as new HTML(regardless of styles/markup being saved).

17 years and 15 duplicates later, this continues to be a massive pain point for our users. I would fix it if I could, but it's too deep... I think solution might be along the lines of bug 731688 comment 6. Richard, I'd like to clarify expected behaviour for this with you: PROPOSAL: For "Edit as new" command on plaintext message, the default format of the new message should be same as when composing a new message from the location of the existing original message, i.e. based on account preference of current identity/server. I.e. if user generally composes in HTML, "Edit as new" should always create a HTML message, regardless of format of original message. But if pref of user's identity is plaintext, and original msg is plaintext, "Edit as new" can be plaintext. For "Edit as new" on HTML message, always use HTML regardless of identity/server pref. Iow, prefer HTML for "Edit as New" (to fix this bug), and only use plaintext for "Edit as new" if original msg AND identity/server pref is plaintext. Original msg Identity/server pref "Edit as new" composition format a) Plaintext HTML HTML (this bug) b) Plaintext Plaintext Plaintext c) HTML HTML HTML d) HTML Plaintext HTML Reasons: a) Original plaintext, pref HTML -> "Edit as new" = HTML 1) ux-consistency with current behaviour: For users composing in HTML, 'Reply' to and 'Forward' of plaintext msg already trigger HTML composition. "Edit as new" is just another way to start a composition based on some original msg, and as seen on this bug and 15 duplicates, users composing in HTML expect to compose in their default format for that identity/server. 2) "Edit as new" of plaintext msg, even if composed in HTML, will still send plaintext msg with default setting of delivery-format: Auto-Detect, due to Auto-Downgrade. Iow, "Edit as new" still preserves plaintext format by default, but allows HTML formatting if desired. So there would be no advantage to force HTML users into plaintext mode and limit their formatting options for nothing. 3) Apart from 1), another reason why "Edit as new" of plaintext msg must always be HTML if user composes in HTML, is bug 140800, which also worsens this bug: Can't switch from real plaintext composition to HTML composition. b), c), and d) are obvious; d) because "Edit as new" must not downgrade the message formatting, but use existing HTML message as template even if user normally composes plaintext. Does that make sense?

If we implement a) from comment 59, this means that "Edit as new" will behave slightly differently from using an explicit template from templates folder to start a new message: Original msg Identity/server pref composition format "Edit as new": a) Plaintext HTML HTML (this bug) "Use template": Plaintext HTML Plaintext Imo, this is required because for an explicit template, we must preserve the user-defined composition format flavor of the template. User is free to save de-facto plaintext template in HTML if we wants to compose in HTML from that template (e.g. by unchecking "Send the message in plaintext if possible", or by sending to self with "Delivery format: HTML", or by including one non-convertible HTML tag). By contrast, user may not have a choice about the format of the original message when doing "Edit as new", so we should always allow HTML formatting for users composing in HTML.

(In reply to Thomas D. (currently busy elsewhere; needinfo?me) from comment #60) > If we implement a) from comment 59, this means that "Edit as new" will > behave slightly differently from using an explicit template from templates > folder to start a new message: > Original msg Identity/server pref composition format > "Edit as new": a) Plaintext HTML HTML (this bug) > "Use template": Plaintext HTML Plaintext So technically, we'll probably need to implement a new nsIMsgCompType::EditAsNew, which will the allow us to implement the new behaviour.

The question would also be: "why was the original message sent as plaintext?". If it's because the receiver accepts only plaintext, editing as HTML makes not much sense. There are surely situations where a change would be needed. Actually, as a workaround, you could "forward as inline" the message and then edit like you want. But if it's doable, I don't impede to do it. Like Jörg wrote in bug 731688, it's very old code and highly complicated and regression prone

To all affected users (doug.kerr, ivan.kuraj, thunderGut et alii): We are aware of this problem and its annoying UX. We apologize for any inconvenience in your workflows caused by this bug. Read through to the end of this comment to get to the good news ;-) (In reply to ivan.kuraj from comment #57) > Same here. Very annoying. I would thinkg it would be relatively easy to fit > this functionality into the one used for new messages... Unfortunately not. Fixing this is entirely non-trivial, looking at the massive complexity of compose pipeline as painstakingly described by Jörg in attachment 8819691 [details] on bug 1323377. If you think it's easy to fix this, you'll be most welcome to try... Here's his developer comment on related bug 731688: (In reply to Jorg K (GMT+2) from comment #8) > I understand that the issue can be annoying. Say you wrote a message that > got auto-downgraded. Now you want to use it again but add some formatting or > an embedded image. > > The [original; T.D.] idea or at least the implementation of editing a message as new is to > reproduce the *exact* same message as the one before. Exact same means that > you get the same format as well. > > The processing is all done in 17+ y/o MIME code (04/20/2000, see first few > lines of mimedrft.cpp) that we will not touch. Besides, the compose pipeline > is highly complicated and regression prone (attachment 8819691 [details]). That's a fact. No mere mortal like myself would be in a position to tackle that code. More so in the current phase of Thunderbird transitioning into more independence, with paid manpower still very limited; we're still largely driven by volunteers. *** Here's the GOOD NEWS ***: I've talked to Jörg (bug 731688 comment 10), one of our key developers, and he has declared his intention of looking into this within the next six months: (In reply to Jorg K (GMT+2) from comment #11) > I have a few burning fires right now, but I'll put it onto the "to do" list > for the next six months. Thank you Jörg, you rock! So let's stay tuned, maybe in a year from now, this problem will be a thing of the past! Good things come to those who wait...

(In reply to Richard Marti (:Paenglab) from comment #62) Thanks for rapid feedback! > The question would also be: "why was the original message sent as > plaintext?". For most cases, I'd guess the answer is: Because Thunderbird unilaterally decided to downgrade user's simple HTML composition into plaintext *after* sending, and without any hint whatsoever in the primary UI. At least I've made that optional, but it's pretty hard to find that checkbox in 4th-level send options where you can switch off Auto-Downgrade behaviour of Delivery-Format:Auto-Detect: [ ] Tools > Options > Composition > General > Send Options > [ ] Send messages as plaintext as possible > If it's because the receiver accepts only plaintext, editing as > HTML makes not much sense. ...but it also doesn't hurt much because if you don't add any HTML formatting, Auto-Downgrade of HTML composition will just send it as plaintext again. Plus, if we also implement bug 731688, users will get to choose the non-default format on a per-message basis by holding Shift key. Recipient-centric Auto-Detect of delivery format is cumbersome, full of bugs, outdated, and pretty useless in today's email landscape. The concept of downgrading full-fledged HTML compositions *after* sending is pretty weird, to say the least. That's why Magnus has hinted to remove recipient-centric Auto-Detect logic completely, and I agree. I'm not aware of any popular email client or webmail which can't read at least the plaintext part of multipart/mixed. Most of them actually render HTML messages without substantial problems. For users who really want or need to send plaintext, I recommend composing in plaintext mode. > There are surely situations where a change would > be needed. Actually, as a workaround, you could "forward as inline" the > message and then edit like you want. Yeah, but that's pretty cumbersome because you'll have to manually add all recipients again. I'd think switching off Auto-Downgrade as explained above makes a better workaround, but unfortunately not applicable for existing plaintext messages; only avoids creating more non-intentional plaintext messages in your TB Sent folder. > But if it's doable, I don't impede to do it. Like Jörg wrote in bug 731688, > it's very old code and highly complicated and regression prone I take that as a "yes" to my proposal of comment 59. Affected users of this bug and 15 duplicates will be forever grateful if we fix this.

Will be fixed by bug 731688.

Awesome. Thanks Thomas and Jorg.

(In reply to Jorg K (GMT+2) from comment #65) > Will be fixed by bug 731688. Just to make sure that this bug 78794 really gets fixed (per comment 59): Can you please make it so that for "Edit as new" of plaintext message, we always compose in HTML, except in this one case: (Original message == plaintext && Identity/server pref == plaintext composition) So combined with bug 731688, here's the full matrix: Original msg Identity/server pref "Edit as new" default "Edit as new" opposite composition format composition format (Shift; bug 731688) a) Plaintext HTML *HTML* (this bug 78794) *Plaintext* b) Plaintext Plaintext Plaintext HTML c) HTML HTML HTML Plaintext d) HTML Plaintext HTML Plaintext

Well, that's a matter of opinion/taste. The user (or myself) might be quite happy to get plain text when editing a plain text message as new even though normally they write HTML. I think making it dependent on the preferred format complicates things. Why don't you also revert row d)? If the preferred format is plaintext, why shouldn't "edit as new" respect that?

(In reply to Jorg K (GMT+2) from comment #68) > Well, that's a matter of opinion/taste. The user (or myself) might be quite > happy to get plain text when editing a plain text message as new even though > normally they write HTML. I appreciate your personal opinion/taste. Auto-Downgrade of simple HTML to plaintext does not satisfy your needs? For "Edit as new" of plaintext msg in HTML editor as proposed here, if you don't add any formatting, message will get sent as plaintext again, isn't it? But I think this isn't about personal preferences, neither yours nor mine, it's about ensuring that our out-of-the-box UX works for as many users as possible and is ux-consistent in itself. Here's what users from 15 duplicates extending over a period of 11 years have unanimously reported: - They set all their preferences to "HTML" (account pref, send options) - They compose in "HTML" mode where formatting is available - TB unilaterally decides to send simple HTML messages as plaintext (without alerting the user to that fact, and without any straightforward way of preventing that); that's arguable at least; some users hate it, some are OK with it, and others like it - Then, user wants to "Edit as new" his very own *HTML* composition, only to find that it's plaintext. - Then "Edit as new" forces plaintext editor without formatting options, in spite of the fact that there's absolutely *nothing* in users preferences and settings which ever suggested a preference for plaintext. You are right: Fixing bug 731688 will be a significant improvement over the status quo, because at least it will now be *technically* possible to start an HTML composition from a plaintext message, using Shift-modifier. However, from an UX and workflow perspective, nothing has changed, because we'll still default to exactly the same behaviour which 16 bugs have complained about. And rightly so, because we'll continue to violate several UX principles: *** UX-consistency: With all of users prefs set to "HTML", there's no reason for us to assume such user wants to compose in plaintext mode (without formatting options), ever, *unless* explicitly instructed by user to use plaintext. There's an explicit per-identity setting in Account options, "Compose messages in HTML format". There's nothing in our UI which suggests that there should be any exceptions to this pref. New msg -> HTML Reply to plaintext -> HTML Forward of plaintext -> HTML Edit as new of plaintext -> Plaintext - WHY!? Iow, "Edit as New" is just another way of starting a new msg in user's preferred format (HTML). Imo that's not the same thing as using templates from templates folder, where templates having plaintext can be assumed a deliberate choice of format. For most users, plaintext vs. HTML is a technicality which is totally meaningless to them as long as their content is not affected. So from a user's POV, they might not even realize that their copy in Sent folder has been converted to plaintext. To them it's just a regular message with some regular content. Their regular (explicit!) composition mode is HTML, so, as described in all of those 16 bugs here, it comes as a surprise when TB unilaterally decides otherwise and suddenly they get stuck in plaintext composition mode. The fact that there'll be a hidden trick to get into their regular composition mode doesn't change that inconsistent and unexpected UX in any way. Which takes us to the next point: *** UX-discovery: So you seem to suggest that if we fix bug 731688, users should just hold Shift key every time they want to "Edit as new" their own HTML compositions, so as to trigger their regular composition mode, which is HTML. Here's a question: How is John Doe going to discover that trick????????????? There's absolutely *nothing* in our UI which points to that option; we don't even offer a direct link to "Keyboard shortcuts" documentation from our Help menu. So how are users going to find out? Back to square one, for the typical scenario as reported here, nothing has changed. *** UX-implementation-level: > User experience principle: interfaces should not be organized around the underlying implementation > and technology in ways that are illogical, or require the user to have access to additional information > that is not found in the interface itself [here: hidden trick of Shift modifier]. > (https://bugzilla.mozilla.org/describekeywords.cgi) In bug 731688 comment 17, you suggest that I am "complicating the proposed solution." Wait a minute... complication for whom? Users or developers? And seriously, with your deep understanding of compose pipeline, how hard can it be to check (even pass through) just 2 parameters: message format (we already know that) && compose-pref (I assume that for a given msg, there must be a property for the compose identity?)? Apart from that single "plaintext" check at the spot where we define the final format, the implementation is simple: for "Edit as new", always use "HTML" as default format, and "Plaintext" for OpppositeOfDefault. Yes, we'd have to disentangle real templates and "Edit as New". I've hinted in bug 731688 comment 10 that we could have nsIMsgCompType::EditAsNew if that's required, or pass a simple "editnew" flag just as we currently pass "forward-inline" flag along the compose pipeline. In case of flag, we can keep the current bundling of Templates and "Edit as new", and *only* at that single spot where we determine the final format, we'll have a tiny conditional for "Edit as new" to do the right thing. After that, it's business as usual. If it's much more complicated for developers, I think we're willing to wait a bit longer for a solution which actually *fixes* this bug without forcing users into new undiscoverable workarounds like "hold Shift while starting your composition". > I think making it dependent on the preferred format complicates things. Why > don't you also revert row d)? > If the preferred format is plaintext, why shouldn't "edit as new" respect > that? Are you really suggesting that "Edit as new" for a full-fledged HTML message should downgrade to plaintext, ripping out inline images and all formatting in the process? I think nobody in their sane mind can expect such behaviour. "Edit as new" means "clone this message and let me modify it". "Cloning" means preserving content as-is, and "let me modify it" requires that we offer HTML formatting options for users who have a known preference for composing in HTML. I think downgrading violates the inherent concept of "Edit as new". Imho, we must err in favor of preserving data integrity, and those users who want to downgrade should use Shift for that. Ymmv. But I can't speak for users who prefer plaintext. Btw, the real solution for that problem is not violating the idea of "Edit as new", but Bug 140800: Implement a switch for plain text/html in compose window, which is historically one of the most-wanted bugs in TB. (In reply to Jorg K (GMT+2) from bug 731688 comment 17) > Please don't stand in the way of fixing a 16 y/o bug (bug 78794) by trying to impose your rules. I think it's quite absurd to blame me for "standing in the way" of fixing this bug, whilst I am its key advocate who has officially acknowledged this as a bug in the first place (comment 41), and it's because of my advocacy, paired with your knowledge and willingness to look into this as a developer, that we're having this discussion, and for the first time after 17 years of inactivity, there's a real chance of finally getting this fixed once and for all. I encourage you to read through all of these 16 bug reports and my comments again to find that this has nothing to do with "imposing my rules", but the legitimite needs and workflows of our users. Let's please be professional and argue this based on UX-principles, not on a personal level. Thank you. Having said that, I totally appreciate that we're demanding a lot from Jörg, who already has more than enough projects to work on, so it's perfectly understandable from his personal pov that he'd rather go for easier implementations. Whereas myself, wearing my hat of UX advocate, am trying to go for the best possible UX, hoping for our best developers to tackle the complexities of implementation...

Btw technically, I think the only thing which makes a template a template is its location in Templates folder (I might be wrong, didn't check). If that's true, in the compose pipeline we could simply check for the location of the original msg to know that it's a template, and then set the corresponding composition format. That doesn't sound like complicated magic to me.

(In reply to Thomas D. (currently busy elsewhere; needinfo?me) from comment #69) > *** UX-discovery: > So you seem to suggest that if we fix bug 731688, users should just hold > Shift key every time they want to "Edit as new" their own HTML compositions, > so as to trigger their regular composition mode, which is HTML. Here's a > question: How is John Doe going to discover that trick????????????? I didn't read your comment fully since I see myself (again) embroiled in an endless UX discussion. The facts are: The system does auto-downgrade if you choose. So if John Doe chooses to auto-downgrade his HTML to plaintext, he will find that when editing a downgraded message as new, he starts off with plaintext. I am *strictly* against promoting plaintext back to HTML by sticking it into a <pre> since I can tell you that a <pre> is very hard to edit. If we don't use a <pre> (bug 731688 comment #13 and bug 731688 comment #14), it's less of a problem. > Are you really suggesting that "Edit as new" for a full-fledged HTML message > should downgrade to plaintext, ripping out inline images and all formatting > in the process? I think nobody in their sane mind can expect such behaviour. It would be consistent to give the user the format they asked for in the account configuration. So if a plaintext user suddenly composes a HTML message, why would they not get that message presented as plaintext when editing? New msg -> plaintext Reply to HTML -> plaintext (losing all rich content!!) Forward of HTML -> plaintext (losing all rich content!!) Edit as new of HTML -> HTML - WHY!? Also, please refrain from any further insults. So far, I have a sane mind, I'm just exploring the options, and always using the predefined compose format seem consistent. Don't you usually wave the flag of ux-consistency? Can we please move the discussion to bug 731688 since I don't want to follow two bugs and cross-cite between bugs.

Status update: Jörg and I have gone beyond the occasional ritual bickering and there's nice and highly efficient teamwork going on in bug 731688. We found that the current implementation is twisted as it conflates 'Edit as New Message' with 'New Message from Template', and the net result is inconsistencies and shortcomings for both actions (looks like a case of ux-implementation-level). So iiuc, Jörg's original patch, like current implementation, tried 'template' behaviour for 'edit as new', i.e. observe *message* format; which didn't help the default case of this bug much. The latest version of Jörg's patch, following his proposal, aligns 'edit as new' with other ways of composing, by observing *account* format (preferred composition mode). This is the current plan: 1) 'Edit as New Message' command to observe *account* format preference (ux-consistency; bug 731688): Regardless of the original message format, you'll compose in the format of your declared preference. Which solves this bug for TB default settings: > plaintext message -> "Edit as New" with HTML account pref -> compose HTML And for plaintext account pref: > HTML message -> "Edit as New" with plaintext account pref -> compose plaintext So that's where we strip HTML, but then, you asked for it! (and you're used to it, from all other flavors like compose, reply, forward, so we're just being radically consistent here). 2) 'Edit as New Message' to allow Shift modifier for opposite *account* preference (ux-consistency; bug 731688) If you're not happy with your own account pref, just hold Shift while "Edit as New", and you'll get the *opposite* of your preferred account format. So anything goes, you can always get what you want. 3) 'New Message from Template': New command to be implemenented (bug 1389083) to observe *message* format and Shift modifier for *opposite* of message format. This is the missing piece of the puzzle, so we now have two clearly distinct actions: 'Edit as New' (observe *account* format) vs. 'New Message from Template' (observe *message* format; default action for Templates; same as double-click on template). I'm considering to hide contextual 'Edit as New' for template messages in Templates folder, and just have 'New Message from Template' instead. Double-click on template should also allow Shift modifier. OT: FTR: "nobody in their sane mind" is an unfortunate/inappropriate phrase for UX discussions; sorry for that, but obviously there was no personal offense meant, and I believe that part of my comment 69 cannot and should not be misconstrued as a personal insult against anyone. It's all about the "sanity" of dataloss behaviour where full-fledged HTML get downgraded to plaintext ("sanitized", hehe...). I wasn't aware that such dataloss behaviour is the implemented default for accounts whose preference is plaintext-composition... So in that case, I'm defeated because Jörg has waved the ux-consistency flag which I usually wave... ;-)

(In reply to Thomas D. (currently busy elsewhere; needinfo?me) from comment #72) > This is the current plan: > ... > 3) 'New Message from Template': New command to be implemenented (bug 1389083) > to observe *message* format and Shift modifier for *opposite* of message > format. 4) Implement "Edit Template" command and UI (bug 1389062); to observe *message* format and Shift modifier for *opposite* of message format (as in 3). Another missing piece, allowing users to edit the actual template. As in 3), assuming that the format of the template message is intentional and consequential, imo we should use the *message* format as composition mode so that the format of the template is preserved by default. It doesn't make sense to keep an explicit HTML template in your templates folder and expect plaintext composition, and vice versa.

Richard, comment 72 and comment 73 outline the grand plan of fixing the current insufficiencies around "Edit as New Message" and explicit Templates. The motivation for the new logic starts here, because 15 duplicates later, we really need to fix this for the default case, without expecting users to know hidden tricks like Shift modifier. The rest is a logical extension of that starting point. So these bugs come as a consistent package. More detailed UX explanations found on each bug respectively. Your UX feedback would be appreciated. Does the overall UX of this plan make sense to you? If there are any caveats, please raise them now. 1) Bug 731688: Change 'Edit as New Message' to observe *account* format preference (ux-consistency with reply, forward etc.; fix this bug 78794) 2) Bug 731688: Improve 'Edit as New Message' to allow Shift modifier for opposite *account* preference (ux-consistency) 3) Bug 1389083: Implement 'New Message from Template'; observe *message* format and Shift modifier for *opposite* of message format. This eliminates the current wrong conflation where "Edit as New Message" acts as "New Message from Template". 4) Bug 1389062: Implement 'Edit Template' (ux-efficiency); observe *message* format and Shift modifier for *opposite* of message format.

SGTM. Using the predefined compose format for 'Edit as New Message' seems consistent. And a template should be used as it is saved. For this it's a template with a reason for it's current format and not only a normal message.

Correcting command label in bug summary.

Fixed by bug 731688.

Hooray! After 17 years, fixed in 18 days... brought to you by Thomas and Jörg! Will still take a while to ship with next full release. Thoroughly fixed: * Improved default behaviour ("Edit as New Message" now respects your account's HTML preference, so editing a plaintext message as new message defaults to HTML composition) * Shift modifier to get the opposite account format if needed (hold Shift while clicking "Edit as New Message"). Some details like plaintext -> HTML conversion still need polishing (Bug 1392052). We also implemented: * Bug 1389083 "New Message from Template" command incl. Shift modifier (observing *message* format) * Bug 1389771 Shift modifier for opposite message format for "Edit Draft" command (followup Bug 1392056 - Shift not yet working for "Edit" button of draft notification bar).