Stuck in proportional font mode

When composing mails in HTML, you can go to Options > Format and select the
format of the mail, i.e. you can go back to plain-text mode. So switching should
be possible, right?
Currently you cannot change from plain-text composing to HTML (when plain text
is default) since the menu item is not available then.
And the HTML -> plain text conversion is not existant for the user since all
styles (formatting) are kept until the message is send.

What would be useful when implementing this: selecting the account from compose
window ("From:" drop-down) should active the respective default composing mode
(HTML or plain text) for that account.

Options / Format just shows and hides the HTML toolbar, your HTML content is
left in tact. What I'm envisioning is an actual converter. If you toggle into
plain text editor, we lose all of the HTML and conver the live message body into
plain text.

I would also like to suggest that the last setting would persist for future
composed emails.

Prog.

"I would also like to suggest that the last setting would persist for future
composed emails.

Prog."

I don't like that idea. No matter which format you prefer, my sense is that most
users use that prefered format 95% of the time, and that changing the format is
often an isolated occurrence. If I want to write one email in html, that doesn't
mean that I want my next email html as well. I still want TB to remember my
preference for plain text.

Lisa. comment #4:

> ...my sense is that most users use that prefered format 95% of the time,
> and that changing the format is often an isolated occurrence

That means that 95% of the time, you won't have to change anything. The
advantage of making this option persistent is that we don't have to add yet
another pref to the already packed-to-the-brim preferences panels.

This "persistent option" concept works very well with features like Auto Image
Resize in Mozilla and Firebird, I don't see why it wouldn't work just as well here.

Prog.

moving these bugs to 0.6

Isn't this more of an editor question?

moving out new feature work

Would like to see this button 2 :D

ditto; cheers to Scott if he can see this through.

I would also like to see this functionality,
and would like to see it made available through the "Options" top-level menue.

Suggestion:

Options ->
  Format... ->
    Plain Text
    HTML

It may be worth it to provide the functionality under a consistent/single
GUI-umbrella for the following three bugs:

This bug, bug 229462, bug 227265.

In each of theses cases, the issue is an instance of
"change global state for the one message being composed".

probalby won't make it for 1.0

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

This is Seamonkey bug 140800.

(In reply to comment #5)
> Lisa. comment #4:
> > ...my sense is that most users use that prefered format 95% of the time,
> > and that changing the format is often an isolated occurrence

  My usage pattern is like what you described. 99% of time, I write in plain
text, but once in a while, I send html or multipart/alternative so that I don't
want this to be persistent.

> That means that 95% of the time, you won't have to change anything. The
> advantage of making this option persistent is that we don't have to add yet
> another pref to the already packed-to-the-brim preferences panels.

 Don't we already have that pref per mail server?

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

When will we have this?
IMHO, this is one of the most important feature.

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

Just needed this feature as well - didn't Mozilla Mail have this option already?
I just needed to send an article from a non-public webpage to a colleague so
sending the link was not possible. This is where HTML-mail is really useful
(i.e. 1% of all cases;)

So my usage-pattern would also be isolated HTML-sending, I'd not want FB to
change my account-setting (would be unexpected, since I applied the setting to a
single mail only).

Will this feature make it into 1.0.1?

I totally want this feature. I keep on getting crappy HTML-format messages with
tiny fonts and bad colors. I expect that when I change the format to "plain
text" that Thunderbird should convert the message right away. Right now it just
hides the HTML toolbar (like you mentioned above) but this is useless to me. I
want the message converted immediately when I change to plain text.

I would like this feature too. I use multiple accounts using global local
folders (one inbox) in thunderbird and use plain text as a default.

Sometimes I need to compose in html and there is no way to it.
The original button idea is good. I would be ok with a drop-down option to the
Write toolbar button or an additional entry to File->New menu item, so that it
is Message & HTML Message.

I can do this, though I have no code for thunderbird yet.

Thanks
Amit

(In reply to comment #22)
> Sometimes I need to compose in html and there is no way to it.

There is, actually -- holding down shift while clicking the Write or Reply
buttons will toggle the compose mode for the new window -- if you normally
compose plain, it will open an HTML mail window, and vice versa. (Also works
for the Forward button if you are setup to forward as attachment; forward inline
causes the shift to be ignored.) No equivalent exists for Edit As New.

But that's just a workaround. It would of course be more flexible if there were
a way to toggle the compose mode once the compose window has opened. One
drawback is that toggling from HTML mode to plain mode will lose any formatting
(per Scott's comment 2), and if you toggle accidentally, toggling back will give
you just the basic conversion without restoring the formatting. I suppose it
could be made Undo-able.

(In reply to comment #21)
> I totally want this feature. I keep on getting crappy HTML-format messages with
> tiny fonts and bad colors.

This is a commendable observation - and there is merit in fixes which help
address one's mail quota and local disk space.

In addition, as I point out in bug 293812 comment 0, if I were able to switch
between html and plain text, I could turn off the mail tooblar and recoup more
than 1/2 inch of screen real estate (perhaps 1 inch for some people).

In addition, it might eliminate the need for at least bugs 228562

(In reply to comment #24)
> In addition, it might eliminate the need for at least bugs 228562

My post in bug 228562 comment 0 explains why a toggle button would not solve the
shift+forward issue. First of all, the way that shift+forward is not consistent
with the shift+ behavior of the other compose buttons, so one could argue it
should be changed for consistency's sake if for nothing else. Second, in the
case when a user who defaults to plain text wants to forward an html email with
its html intact, the toggle button would not work because once the forward
button is clicked, the html information is already lost. The only way a toggle
button would solve this problem is if it were on TB's main toolbar, not the
compose window's toolbar, so that the toggle occurred before the forwarding
message is begun. That is of course a possibility, but not yet addressed as an
option by this bug report.

(In reply to comment #25)
> (In reply to comment #24)
> > In addition, it might eliminate the need for at least bugs 228562
>
> My post in bug 228562 comment 0 explains why a toggle button would not solve the
> shift+forward issue. First of all, the way that shift+forward is not consistent
> with the shift+ behavior of the other compose buttons, so one could argue it
> should be changed for consistency's sake if for nothing else.

quite right - my bad

should this be depends on bug 140800?

See bug 254931 comment 1. I think that Forward Inline, like Edit As New,
probably should default to opening in the same mode as the original message --
if you got an HTML message, forwarding it should result in an HTML composition
regardless of the setting. (The information from Neil that I quote at that
comment implies that there is some basic similarity between Forward Inline and
Edit As New already, so perhaps this is in fact what's intended.)

Then, as long as the shift+tool hack is being relied on, Shift+Forward would
reverse the expectation; and when/if the in-window mode-switch is in place, the
original HTML information shouldn't be lost on a forward unless the user
explicitly forced it. However, per bug 293649, there is some *other* problem
with Forward Inline where at least some formatting is getting discarded even
when the compose window is HTML.

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

There is a extension that gives you the option to choose the format when
replying. It is not a full solution for this bug, but it helps a bit.

http://nic-nac-project.de/~kaosmos/changequote-en.html

On small problem though, does not work yet with 1.5b1 :-(

My two pennies ...

I really would like to see a "switch format" button. In the following way:

- If the mail is plain text, reply/forward would open a plain text editor. A switch is present which lets me change to HTML editing. The text already present is a simple paragraph in the resulting mail.

- If the mail is HTML, reply/forward would open a HTML editor. THe switch wouzld let me change to plain text. _All_ HTML coding information besides line breaks and paragraphs would be lost. Switching back to HTML would _not_ get me back to the original format.

- A new mail is always opened in the users default setting. Switching between format is handled like above.

I agree to Comment #30 except I would like an override setting to ignore the format of the email you are responding to. For example if I receive a html formatted email and I reply to it with my override setting set to plain text, I would get a plain text editor without a prompt about losing formatting. This saves me from having to change format every time I reply.

That setting could be set by a prompt that shows up when the user has replied and immediately changed to the other format a few times. For example: "Do you want to save a preference to always use plain text format when writing email? Yes/No". But now we're getting fancy. Just being able to change format would be great! Thanks.

I agree with the Toggle. In Evolution on Linux this happens wonderfully. I don't know how it remembers, but I have it set to create email in plain text by default. If I reply to or forward an HTML mail, it initially does it as plain text (strips the html out), but if I go to Format->Html, the HTML reappears like magic.

I understand this would be hard to do in keeping the HTML, but it works beautifully for the user.

I just found out about Shift+"Reply" to get it to do the HTML, but it doesn't work on Forward, which is where I would need it most. The Shift hack is completely unknown and should have some sort of menu item until another way is coded.

In response to comment #32

Forward is more or less useless in TB. Until forward is fixed, you can click "reply" and change the "Re:" to "Fw:", and manually edit the recipients list. There are all kinds of problems with "forward", ranging from crummy formatting (read: different from when replying to the same email), to inline images that don't get sent and TB crashing.

I thought that Options > Format > Plain Text Only is this toggle and is simply utterly broken -- it only changes your message to plain text when you Send or Send Later. So I filed bug 339887. If Options > Format is not intended to do what this bug requests then there should be a separate bug that it is very confusing and should be renamed, e.g. Options > **Message Delivery Format** > Plain Text Only.

I expect to lose all HTML formatting when I switch to Plain Text, I don't expect it to magically reappear if I switch back. I can Undo or compose a new message.

Thanks for the Shift-click workaround! Until this bug is fixed it's a shame that the workaround is so hidden.

I'm not going to get to this for 2.

Please also consider the comments in bug-ID 321784 regarding this issue

sorry for the spam. making bugzilla reflect reality as I'm not working on these bugs. filter on FOOBARCHEESE to remove these in bulk.

Filter on "Nobody_NScomTLD_20080620"

Regarding Comment #1 (April 2002):
one bad thing with this workaround is that it doesn't apply to the keyboard shortcut Cmd+Shift+N, and isn't present in the menu next to New > Message.

this seems really counter-intuitive, and each single time i need to switch from text to HTML, although i *know* that there *is* a trick, i'm forced to turn to google and find the solution in some blog...

the one who fixes this gets a free beer from me! ;)

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

Bug 229117 has a different, somewhat orthogonal, probably less promising approach to this.

(In reply to Kim Xupei from comment #30)
> Regarding Comment #1 (April 2002):
> one bad thing with this workaround is that it doesn't apply to the keyboard
> shortcut Cmd+Shift+N, and isn't present in the menu next to New > Message.
>
> this seems really counter-intuitive, and each single time i need to switch
> from text to HTML, although i *know* that there *is* a trick, i'm forced to
> turn to google and find the solution in some blog...
>
> the one who fixes this gets a free beer from me! ;)

Oh yes! Another one (a whole liter!) from me too! :)

Im my opinion this doesn't fit together: preventing the user to switch easily to html-mails and forcing the use of the mouse ;)

Hi guys, this bug is older then ELEVEN years and still not fixed. There are n > 20 duplicates of this bug (view https://bugzilla.mozilla.org/show_bug.cgi?id=216132 for another set)
In my opinion it is clear that this should be fixed and instead of just mapping duplicates.

My idea:
It annoyed myself so much that everybody just comments on that instead of doing sth, that I volunteer for fixing this bug and getting IT done. Anyway as I have never worked with the Mozilla sources before it would be very cool to have one of the elder developer to help me out in case I need help.
Is there anybody out-there?

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

FTR:

Duplicate big twin bug 216132 was filed by Scott McGregor, one of the original developers of TB (now gone). It was until now filed against TB Product, but for all practical and technical purposes will be better consolidated here in MailNews Core Product.

Bug 216132 comes with it's own impressive collection of 13 duplicates (which will be transferred to here, too), and 52 votes (intersections possible; users have been asked to transfer their votes here).

Here's the original description of the bug (worth noting):
(In reply to Scott MacGregor from comment bug 216132, comment 0)
> I'd like to add a button to the mail compose window. Clicking on this button
> would toggle editor between plain text and HTML. This may not even be
> possible. Just something that came up in the forums that I thought was a good idea.
>
> You would also need a dialog to come up and warn the user when converting
> from HTML to plain text about loss of formatting data.

(In reply to weirdkeen from comment #34)
> Hi guys, this bug is older then ELEVEN years and still not fixed. There are
> n > 20 duplicates of this bug (view
> https://bugzilla.mozilla.org/show_bug.cgi?id=216132 for another set)
> In my opinion it is clear that this should be fixed and instead of just
> mapping duplicates.

+1 :)

It's a manpower issue, especially now that TB is largely maintained by the volunteer community, i.e. volunteers like you and me...

> My idea:
> It annoyed myself so much that everybody just comments on that instead of
> doing sth, that I volunteer for fixing this bug and getting IT done.

weirdkeen: thank you, that's awesome and most welcome! :)

> Anyway as I have never worked with the Mozilla sources before it would be very cool
> to have one of the elder developer to help me out in case I need help.
> Is there anybody out-there?

Yes :) There are definitely Mozillians out there who are willing to assist, including developers, both Mozilla employees and volunteers, and some of them are already cc'd on this bug so I expect them to speak up here and/or contact you via private mail. For a tentative overview, pls consult https://wiki.mozilla.org/Thunderbird/Community_Members
For advice, it's probably best to ask publicly on IRC (https://wiki.mozilla.org/IRC):
irc://irc.mozilla.org/maildev, or irc://irc.mozilla.org/thunderbird
...or contact people there (IRC nicks found on above community members page);
For other options, you might want to have a look at
https://wiki.mozilla.org/Thunderbird/CommunicationChannels

For the coding part, here are some links I'm aware of (others might know more):
https://wiki.mozilla.org/Thunderbird/Contributing_patches
https://developer.mozilla.org/en-US/docs/Introduction
https://developer.mozilla.org/en-US/docs/Simple_Thunderbird_build

(As for myself, I think I can count myself among TB's elders, but I'm more on the UX and bug triaging side than on the developing side, and usually not on IRC - use private email instead)

A good starting point for all things TB (albeit with outdated corners) is
https://wiki.mozilla.org/Thunderbird:Home

weirdkeen, welcome onboard! :)

This is really a front-end bug, so it's not technically in mailnews core. Anyway, if it gets fixed it should can be ported over later.

As a first bug, this may not be an easy one to do.

The next step for this bug is to clarify the desired UI and behaviour in detail.

Any chance of this ever (cf. the date of this page, and others like it) being implemented? As to

> The next step for this bug is to clarify the desired UI and behaviour in detail.

I think most people would be happy with a switch, in the composition window, that temporarily - i.e. until clicked again or until Thunderbird restart - change the text composition mode.

Created attachment 8863109
Thunderbird - 2017_0429 - HTML-Plain text composition switch.JPG

When I compose in HTML, the option in the screenshot allows me to switch modes. However, it's not there when composing in plain text.

So I suggest making the option available when composing in plain text, and using it to switch between modes.

You're confusing composition mode with delivery mode.

If you compose HTML, you can send HTML or "dumbed-down" plain text (or both).
If you compose plain test, you can only sent plain text.

If I understand comment #0 correctly, what is requested here is to change composition mode. If you started a plain text composition, you want to switch to HTML mode. There's a lesser need to switch a HTML composition the plain text, since as observed, you can force plain text to be sent.

As the compose peer I'd say that we won't spend any effort on this. But we'd consider accepting a patch. Now with compose window recycling removed (in TB 48) this is more feasible, before it was just technically impossible.

Let's note the following:
- This is not a malfunction, but an enhancement request.
- While we had compose window recycling, this was impossible technically.
- TB is a volunteer driven project, so someone in the community needs to step up and
  submit a patch.
- TB only employs people to guarantee bare minimum functioning of the project, and that
  doesn't include enhancements like this one.
- In the scheme of things, this is a "nice to have" and we have many more pressing issues
  (like losing drafts or sent messages when they can't be stored due to IMAP failure.
  That bug is really 17 years old and more important).

I think there is a malfunction. The malfunction is that sometimes I can not switch the delivery format to, e.g., HTML. There's just no menu element "Options > Delivery Format".

For example there's a draft mail I created on my iPhone earlier which includes images.

When I edit this draft mail using Thunderbird, Thunderbird is in this strange mode and thus I can not switch delivery format nor add rich text formatting. The images are represented as attachments. That's very bad.

Now, when I add an element of rich text on my iPhone to this draft and edit this draft in Thunderbird, Thunderbird switches to "delivery format = auto detect" and shows rich text formatting controls. Additionally, the images are now inline with the text and I can move them around or rearrange them.

Speaking of iPhone, I don't know why this issue is so complex with Thunderbird. In Apple Mail there's a simple button available in the composition window to toggle between plain text and rich text editing. That's all. Just works.

Please don't confuse switching *delivery* format with switching *composition* format. You *cannot* switch composition format, once you're in plain text compose, there is no way to switch to HTML/rich text. That's what this bug is about. If you're in HTML compose, you can "dumb" the delivery format down to plain text. You can easily tell the difference by checking whether the formatting toolbar is available.

I assume that the iPhone creates plain text drafts, when you edit those, you're in plain text mode ("strange mode"), and again, the issue reported here is you're stuck with this mode and cannot switch to HTML. It would be interesting to see a draft created by the iPhone and stored in an IMAP folder. Can you please attach a sample.

BTW, you can enter plain text composition mode by selecting it as default in your account settings, or using <shift>-chick-reply or <shift>-click-write. If you're reporting bugs since 2002, getting to know all the functions TB offers is important.

When you add formatting to the message on the iPhone, it will be stored as HTML and TB will pick that up.

> In Apple Mail there's a simple button available in the composition window to
> toggle between plain text and rich text editing. That's all. Just works.
I believe Apple software and hardware aren't free of charge. TB is a volunteer driven project, so if this issue really annoys you, get up to speed and fix it yourself, or, instead of buying a new iPhone, spend this money to hire a developer to implement this.

> For example there's a draft mail I created on my iPhone earlier which includes images.
If you create a draft with the iPhone which contains embedded images, then the iPhone shouldn't store that as plain text. That sounds like a bug in the iPhone software. Maybe you should enquire with Apple about it. But let's see such a draft to assess it better.

(In reply to Jorg K (GMT+2) from comment #44)
> Please don't confuse switching *delivery* format with switching
> *composition* format.

I didn't. To the best of my knowledge there is no UI element that allows a user to directly switch composition mode in TB. There's however the account setting parameter "Compose messages in HTML format". With this parameter set, a new compose window sports a rich text formatting toolbar and the menu "Options > Delivery Format" is available.

> You *cannot* switch composition format, once you're in
> plain text compose, there is no way to switch to HTML/rich text. That's what
> this bug is about.

I agree. This is the "malfunction" I was talking about. The menu for selecting delivery format should be available always.

> If you're in HTML compose, you can "dumb" the delivery
> format down to plain text. You can easily tell the difference by checking
> whether the formatting toolbar is available.

I disagree. Even if you "dumb down" the delivery format from HTML to plain text, the formatting toolbar is still available. At least in my version of TB 52.1. Just tried it. If you switch to plain text delivery format, the content is "dumbed down" on sending, e.g., bold text is encoded by putting the text in between asterisks (e.g., "*bold*")

Regarding a draft created by iPhone, I'll have to check.

And yes, I know how to configure TB functions - at least since 2002. ;-)

(In reply to Daniel Kabs, reporting bugs since 2002 from comment #46)
> > You *cannot* switch composition format, once you're in
> > plain text compose, there is no way to switch to HTML/rich text. That's what
> > this bug is about.
> I agree. This is the "malfunction" I was talking about. The menu for
> selecting delivery format should be available always.
No, when you're already in plain text composition, you cannot send that plain text as HTML, hence no menu.

> Even if you "dumb down" the delivery format from HTML to plain
> text, the formatting toolbar is still available. At least in my version of
> TB 52.1. Just tried it. If you switch to plain text delivery format, the
> content is "dumbed down" on sending, e.g., bold text is encoded by putting
> the text in between asterisks (e.g., "*bold*")
Exactly. Then composing HTML, the formatting toolbar is always present regardless of which *delivery* format you chose. That's changed in bug 1288914. You can add bold/underline, etc. and when turning this to plain text that is converted to *bold* and _underline_. Lists are also converted.

I'd really like to bring the discussion to a close here. The bug is about a facility to "upgrade" a plain text composition to rich text. Switching from rich text to plain text is dangerous since you'd lose all your formatting and embedded images.

More comments won't get us anywhere, we need someone to implement this to move forward.

(In reply to Jorg K (GMT+2) from comment #47)
> > I agree. This is the "malfunction" I was talking about. The menu for
> > selecting delivery format should be available always.
> No, when you're already in plain text composition, you cannot send that
> plain text as HTML, hence no menu.

No, that "hence" is wrong. "hence" means "consequently" or "for that reason" but this implied causality just does not exist here.

The menu is not there because Thunderbird is broken to this regard. In the case at hand (starting the composition window in "plain text mode"), the menu should be there with the parameter "delivery format" set to either "auto-detect" or "plain text only".

As I said, further comments don' help here:

Plain text composition is sent as plain text, so the "auto-detect" would give the same as "plain text only". The menu isn't needed, hence no menu.

(In reply to Jorg K (GMT+2) from comment #49)
> As I said, further comments don' help here:
>
> Plain text composition is sent as plain text, so the "auto-detect" would
> give the same as "plain text only". The menu isn't needed, hence no menu.

The menu is needed as the user might want to switch to "rich text" during composition.

Confusing *delivery* format with *composition* format again? :-(
The delivery format menu (auto-detect from the composition format) won't allow you to switch composition format.

(In reply to Daniel Kabs, reporting bugs since 2002 from comment #50)
> The menu is needed as the user might want to switch to "rich text" during
> composition.

Once switching to "rich text" (HTML) composition becomes possible (this bug), there will also be the menu needed to do it.

There's only one switch needed, be it the "delivery format" (more switches will confuse the hell out of the user). Everything else is straightforward and implicitly done depending of the chosen "delivery format". If delivery format is switched, text is converted accordingly (rich text to plain text or vice versa). The formatting toolbar is always visible as it also works for plain text (e.g., *bold*). What's wrong with this?

There is a lot wrong with this since once again you're mixing *delivery* with *composition* format.

TB has an intricate system to ship the appropriate format to the recipient as stored in the address book:
  Prefers message formatted as ...

So the sender might compose rich text and the recipient will receive "embellished" plain text.

Also, there shouldn't be a formatting toolbar for a plain text composition, since you can't apply text colour, size, etc. If you want bold or underline, use *bold* or _underline_, all plain text fans know that.

As I said before, all that can be said here was said already. I am the compose peer in Thunderbird and I can tell you that we will not use the delivery format switch to change composition format.

If someone wants to propose a patch, please go ahead.

(In reply to Jorg K (GMT+2) from comment #54)
> There is a lot wrong with this since once again you're mixing *delivery*
> with *composition* format.

I rather suggested that the composition mode should be set implicitly by the delivery format (or vice versa). Apple Mail only has one button to switch between rich text and plain text mode. What's wrong with this solution?

> TB has an intricate system to ship the appropriate format to the recipient
> as stored in the address book:
> Prefers message formatted as ...

This system could be used to set the default mode when starting a new mail or replying to a mail. As I see it, it's only a "guideline" and the user should be able to change the mode during composing.

> So the sender might compose rich text and the recipient will receive
> "embellished" plain text.

So, what's wrong with this? Or what exactly do you mean with "embellished" text? This _kind_ of *text* styling? Same happens if I start in rich text mode/HTML delivery format and switch to plain text delivery format before sending.

> Also, there shouldn't be a formatting toolbar for a plain text composition,
> since you can't apply text colour, size, etc. If you want bold or underline,
> use *bold* or _underline_, all plain text fans know that.

Why? Of course there could be a formatting toolbar even for plain text composition. Actually there is a formatting toolbar when switching from HTML delivery format to plain text delivery format and it *allows* to _format_ the text. It even allows to change fonts (that's something I don't like or understand). Apple Mail removes all formatting when switching composition mode to plain text and disables formatting toolbar.

> As I said before, all that can be said here was said already. I am the
> compose peer in Thunderbird and I can tell you that we will not use the
> delivery format switch to change composition format.

Why not? What is the user story supporting your view? Are you preserving the "real" plain text mode for the fans of plain text mails as those fans don't like a formatting toolbar? Then maybe bug #1288914 should have been implemented by removing all styling when switching to text mode (and the formatting toolbar) as mentioned in bug #1288914 comment 9 as solution 1.

> If someone wants to propose a patch, please go ahead.

What exactly (UI elements, behaviour, etc) do you want to be implemented? A UI element in the composition window to switch from "real" plain text mode to rich text editing? What does this mode switch encompass, e.g., enabling formatting toolbar, enabling the "delivery format menu"? I don't understand why you prefer an additional UI element for this switch to happen.

(In reply to Daniel Kabs, reporting bugs since 2002 from comment #55)
> What exactly (UI elements, behaviour, etc) do you want to be implemented?
Personally, I'd implement what was asked for with minimal change since every change we make breaks someone's workflow.

So on the options menu I'd have a new menu entry.

When in a plain text composition, it would read:
Convert message to rich text (HTML).
That would show the formatting toolbar, add the usual HTML options, like delivery mode, to the menu and convert the content of the message. Turn what I called embellishment (*bold*, _underline_, /italics/) into the respective HTML tags. That's quite hard, I think, since we also need list processing and superscripts (x^2).

When in a HTML composition, the new option would read:
Convert message to plain text.
When using this option a big warning would be displayed that you will now lose most formatting. Maybe there should be a check-box to disable the warning next time.
That would hide the formatting toolbar, remove the usual HTML options, like delivery mode, from the menu and convert the content of the message. Bold, underline, italics, superscripts, lists are all converted to plain text.

Optionally there could be a reduced formatting toolbar for plain text compositions that would offer minimum formatting, like bold, underline, italics, etc.. You can see that in many web editors which add markdown (* ** _) to messages. Note that it would be special TB markdown, since TB uses * _ and /.

Big job for little gain, that's why it was never attempted.

Could be some Google Summer of Code project.

Convertig that text "embellishment" to html tags can be optional and nice to have for later. I think no one can really expect that.

(In reply to Jorg K (GMT+2) from comment #56)
> When in a plain text composition, it would read:
> Convert message to rich text (HTML).
> That would show the formatting toolbar, add the usual HTML options, like
> delivery mode, to the menu and convert the content of the message. Turn what
> I called embellishment (*bold*, _underline_, /italics/) into the respective
> HTML tags. That's quite hard, I think, since we also need list processing
> and superscripts (x^2).

I vehemently disagree with this interpretation of the proposal. First, if that type of formatting is desirable, there are plugins such as "Markdown Here" that can be used to accomplish that. Second, it means that converting to HTML is actually a *lossy* change, not lossless.

Under all circumstances, switching from plaintext composition mode to HTML composition mode and then back again without making edits should be effectively identical to not switching at all.

Switching from a *formatted* HTML email to plaintext email is unavoidably lossy. There should be an alert dialog about that, just as there is in Outlook or Apple Mail, and that's fine. But trying to be "smart" when converting plaintext to HTML, when that wasn't *explicitly requested*, would be a nightmare.

Plus, omitting this "smart" behavior would also make the feature tremendously simpler to implement. (And do so without breaking user expectations.)

I think the best description of the desired behavior has already been given (in the first comment on bug 216132):

> I'd like to add a button to the mail compose window. Clicking on this button
> would toggle editor between plain text and HTML. This may not even be possible.
> Just something that came up in the forums that I thought was a good idea.
>
> You would also need a dialog to come up and warn the user when converting from
> HTML to plain text about loss of formatting data.

And much like weirdkeen (comment #34), I would be happy to try to implement that—but I don't know where to do it.

Can someone point at the specific source code file(s) where such a feature would likely live?

(In reply to mikeweilgart from comment #59)
> (In reply to Jorg K (GMT+2) from comment #56)
> > When in a plain text composition, it would read:
> > Convert message to rich text (HTML).
> > That would show the formatting toolbar, add the usual HTML options, like
> > delivery mode, to the menu and convert the content of the message. Turn what
> > I called embellishment (*bold*, _underline_, /italics/) into the respective
> > HTML tags. That's quite hard, I think, since we also need list processing
> > and superscripts (x^2).
>
> I vehemently disagree with this interpretation of the proposal. First, if
> that type of formatting is desirable, there are plugins such as "Markdown
> Here" that can be used to accomplish that. Second, it means that converting
> to HTML is actually a *lossy* change, not lossless.
>
> Under all circumstances, switching from plaintext composition mode to HTML
> composition mode and then back again without making edits should be
> effectively identical to not switching at all.
>
> Switching from a *formatted* HTML email to plaintext email is unavoidably
> lossy. There should be an alert dialog about that, just as there is in
> Outlook or Apple Mail, and that's fine. But trying to be "smart" when
> converting plaintext to HTML, when that wasn't *explicitly requested*, would
> be a nightmare.

I agree with comment 58 and comment 59 that "smart" upgrading from embellished plaintext to real HTML formatting is a can of worms that should be avoided. We really can't predict the meaning of such embellishments, and we could never remove the embellishment characters (as we already don't remove them when reading them as formatting within plaintext), so user needs to go through all of his text anyway to remove them, then it's just the same to apply formatting where wanted.
Let's be honest, up- and downgrading of messages doesn't make much sense. Better don't start in plaintext mode when you want formatting. Better don't start in HTML mode when you don't want formatting and you want to be sure of that (otherwise, current auto-detect will just down-convert to plaintext for you when there's (almost) no formatting). I think the need for this feature has also become much less now that "Edit as new" of plaintext messages will go into HTML mode when that's your default. So users are much less likely to get stuck in plaintext mode against their will, which I guess was one of the key use cases for this feature. Please note that (at least after our message formatting/Shift-key-for-opposite-format spree, which is about to land), you can always hold Shift key to get opposite of the expected/current format when going into compositions. E.g., hold Shift while clicking "Edit" on draft and you'll end up in the opposite composition mode of what you'd normally get. Unfortunately that trick is not discoverable, but for the initiated, it might reduce the need for conversion from inside messages again.

> Plus, omitting this "smart" behavior would also make the feature
> tremendously simpler to implement. (And do so without breaking user
> expectations.)

+1

> I think the best description of the desired behavior has already been given
> (in th...

Then, the template for localized UI strings lives in dtd files (for dynamic strings, in properties files), so whereever you have visible strings in your UI, you outsource those to here, e.g. label="&stringEntityID;"

https://dxr.mozilla.org/comm-central/source/mail/locales/en-US/chrome/messenger/messengercompose/messengercompose.dtd

(In reply to Thomas D. (currently busy elsewhere) from comment #60)
> Please note that (at least after our message
> formatting/Shift-key-for-opposite-format spree, which is about to land), you
> can always hold Shift key to get opposite of the expected/current format
> when going into compositions. E.g., hold Shift while clicking "Edit" on
> draft and you'll end up in the opposite composition mode of what you'd
> normally get. Unfortunately that trick is not discoverable, but for the
> initiated, it might reduce the need for conversion from inside messages
> again.

In actual fact, if that method were mapped to an actual menu item (so it's keyboard-shortcut-able), I would be fine with that. For instance, it doesn't seem that "Control-Shift-R" or "Control-Shift-L" are mapped to anything currently. (On a Mac, s/Control/Command/g.) That would give a consistent behavior if those keyboard shortcuts mapped to the same behavior as shift-clicking currently does. (Since Control-R is already mapped to "Reply" and Control-L is "Forward.")

*Personally,* I don't actually care that much about switching back and forth *while* composing (though the feature should still be implemented!). But I do think it's an absurd regression that you MUST use the mouse to get the alternate composing method.

It seems to me that such a feature would be extremely simple to implement as it would just entail mapping a keyboard shortcut to activate already existing functionality.

For bonus points, the menu bar menu could dynamically change when the Shift key is held down, to replace "Reply" with "Reply With Plain Text" or "Reply With HTML" and replace "Forward" with "Forward As Plain Text" or "Forward As HTML" (according to whether the Account Settings -> Composition -> "Compose messages in HTML format" checkbox is *checked* or *unchecked*, respectively—so in either case the "hold shift" option would show the *alternate* composing method, mirroring the current shift-click functionality).

I don't know how widespread dynamic toggles of menu bar menus are in Linux or Windows applications, but they're quite common in macOS. You can see a simple example on the Apple menu; click it and then toggle the "Option" and "Shift" keys to see how it changes.

For now I will continue using the clicking workaround. I'm not a Javascript guru.

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

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

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

The shift+click workaround does NOT work for me when using the normal interface with the curvy-arrow "reply" buttons. No matter what I do, the account default for HTML or plain stays.

I figured out that the shift+click works ONLY if I choose "reply" from a menu, either the "Message" menu or from contextual menu with a right-click.

Seems absurd that the functionality is clearly present but the UI has nearly no way to access it in a straightforward sense.

(In reply to wolftune from comment #67)
> The shift+click workaround does NOT work for me when using the normal interface with the curvy-arrow "reply" buttons. No matter what I do, the account default for HTML or plain stays.

I now have shift+click working in the normal interface since I got a more recent Thunderbird update since a couple months ago.