User Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:47.0) Gecko/20100101 Firefox/47.0 Build ID: 20160606114208 Steps to reproduce: I start editing a new mail. I change the delivery format into plain-text only. Actual results: The text lost a bit of the formatting but still some remains, like different fonts (mix of monospace/proportional). Expected results: The text should be converted to plain-text mode. All text should be displayed in a single font. Ideally user-defined, if not any default monospace font (like the default desktop monospace font). Current implementation is just insane; there is no way one can change the displayed font, so formatting the message to display correctly is difficult. Apparently a similar bug (Bug 21128) was filed in 2008, let's hope some progress have been done since then. In any case, converting a mail from HTML to text is straightforward: just remove all HTML tags. Also, we don't want to convert it back to HTML. If formatting is lost, the best is to warn the user that message will be converted to plain-text and any formatting will be lost.

As you've noticed, bug 21128 was marked WONTFIX. So you're asking the same again, and the answer will be the same. Switching the delivery format will *NOT* convert the message content. If you wish to compose plain text e-mail, you have two options: 1) Configure your account to use plain text only. 2) Use the shift-key when clicking Write (new message), Reply or Forward and you will get a plain text composition. As for "just remove all HTML tags": We do have functionality in the box that lets us convert HTML to plain text. It handles links, converts <b>xx</b> to *xx*, handles underlines, etc.

Hello, Thanks for quick feedback. I did not know about the shift-click combo. Very useful, and I certainly will use it a lot whenever I need to reply in text mode. Regarding the original request, I understand this seems an old topic. I found also the following references, like bug 216132 and bug 140800. It seems the main difference between now and then is that the menu option is clearly stated "Delivery Format". However I still do think that the current UI is broken. You insist that changing the delivery format will not change the message content, but still, selecting plain-text as delivery format removes the formatting button in message edition window. For me this is really inconsistent. Either you let the user format the message however it likes (for instance using bullets, text indentation, which then get indeed very well converted by the built-in converter), basically make no UI change, or you apply the built-in conversion immediately and switch to plain-text edition like the shift-click mode. Now current solution is just a weird mixed one. If your initial message contains various fonts and formatting, then switch to plain-text delivery format, and continue editing the text, you end up relying on the existing style, and for instance adding text next to a bold text becomes bold as well, new paragraphs keep indentation, etc.

Yes, I agree, the current UI is completely silly, not to use a stronger word. When the delivery option is switched to "Plain Text Only" the formatting toolbar is removed for no good reason since at that point the composition can already contain all sorts of formatting. I believe the reasoning is to discourage the user to add even more formatting which would be lost at send time. I know I had this conversation before with one of our developers, perhaps Aceman, but I can't locate it now. So let's have it again: Aceman and Richard: When you switch the delivery option of a HTML composition to plain text, the formatting toolbar is removed. *Why?* As the reporter stated, these two options seem consistent and reasonable: 1) When switching a HTML composition to plain text delivery, convert the HTML to plain text immediately, after displaying warning that dataloss is going to occur. Then remove the formatting toolbar. Of course once in plain text, it doesn't make much sense to switch back to HTML. 2) When switching a HTML composition to plain text delivery, leave the formatting toolbar in place since the composition most likely already contains formatting. The user can switch back to HTML mode without losing any data/formatting. In the times of window recycling option 2) was the only possible option, since a window could not change composition type. I'm not sure whether this restriction still exists.

I agree, we should leave the formatting toolbar visible. Immediate change to plain could also be bad when the user selects plain text delivery by accident and all formatting would be lost. Converting it before sending should be enough.

OK, let's use this bug here for the purpose instead of opening a new one.

We need to decide whether we want to get rid of this ancient old quirk ;-)

I vote indeed for leaving the formatting toolbar visible, even when we select plain-text delivery format. The plaintext conversion in TB is really powerful; it makes actually sense to edit the text using HTML formatting (like bullets or indentation), and have TB convert it nicely to plaintext. Now that I tested this, I think I won't use that much the shift-click combo in fact. Also, but maybe OT, regarding plain-text edition mode, the UI does not hint about the shift-click combo. Maybe a hinting text over Write/Reply/Forward buttons would help.

Comment on attachment 8775122 [details] [diff] [review] One liner if we want to do that. Review of attachment 8775122 [details] [diff] [review]: ----------------------------------------------------------------- OK, if you see a use case of always editing in HTML and then convert to plain text. But I'd like to hear if maybe Magnus remembers why the menus/toolbar was being hidden. ::: mail/components/compose/content/MsgComposeCommands.js @@ +3168,4 @@ > format_menu.hidden = hideMenus; > insert_menu.hidden = hideMenus; > view_menuitem.hidden = hideMenus; > // Hide the HTML toolbar if the output format is plain text This comment seems incorrect now.

Thanks. (In reply to :aceman from comment #8) > But I'd like to hear if maybe Magnus remembers why the menus/toolbar was > being hidden. Sure. > This comment seems incorrect now. Will fix before landing. Thanks for noticing.

Comment on attachment 8775122 [details] [diff] [review] One liner if we want to do that. Review of attachment 8775122 [details] [diff] [review]: ----------------------------------------------------------------- I don't know, but probably (incorrectly) to discourage adding more formatting which might not make it completely all the way to the recipient

https://hg.mozilla.org/comm-central/rev/14e74c55c883 (no uplift for this).