Stuck in proportional font mode

[Stuart Bishop]

If you start a message in HTML mode, choosing Options->Format->Plain Text Only
switches to plain text mode but the compose window does not switch to a
monospace font. Starting a message in plain text mode uses the correct font.

https://bugzilla.mozilla.org/show_bug.cgi?id=216132: https://bugzilla.mozilla.org/show_bug.cgi?id=216132

[Toddandmargo-n (toddandmargo-n)]

Hi All,

   Would you add the following to the wish list:

   Although most of my letters are composed in text, there is are times when
it would be nice to compose one in HTML without having to go back and forth
between preferences. Suggestion: put something, somewhere in the compose
window that will allow me to do a one time toggle between text and HTML.

Many thanks,
--Tony
<email address hidden>

[Kryptolus (kryptolus)]

Shift+Click on the Compose icon and it opens up a compose window of the opposite
setting ...

[Toddandmargo-n (toddandmargo-n)]

   Cool. Thank you. :)

   But, very hidden from the user. How about one of those pull down
arrows on the right corner of the compose button? Also, include an
entry for it in the Messages pull down menu.

Many thanks,
--Tony

[Bzbarsky (bzbarsky)]

I was just looking for something like this a few days back.... and there seem to
be no dups. :)

[Jruderman (jruderman)]

Options > Format allows you to select how the message will be sent, but I don't
see a way to switch between plain text and html composition.

[Bugzilla3 (bugzilla3)]

Just reminding you that IE has that on compose window (Format menu) and it's
easily accesible for both new message compose and for reply. Mozilla has only
the shift-click approach (that I wasn't knowing about until I came here) that,
fortunately, works for replies too.
Since html mail is a commodity these days, i'm guessing most users will be
disappointed because now we don't have that option in the UI.

[Mozillauser (mozillauser)]

I have the same problem as Jesse Ruderman.

Can anybody tell me why the choice between HTML and Plant-text composer is
completely missing from my preferences? I did not even know that a plain-text
mode existed. I just went to search for an RFE asking for the addition of one,
and was surprised to discover it already existed. I tried the trick of
shift-clicking the "Compose" button, and that worked just fine, but if I look in
Preferences under "Mail & Newsgroups" under "Composition" I see no option for
changing which is the default.

[Mozillauser (mozillauser)]

D'oh! I should have mentioned my build ID. 2002071104 trunk on Linux.

[Toddandmargo-n (toddandmargo-n)]

Hi James,

    They stuck it under "Mail and Newsgroup Account settings".

--Open a mail window
   --click on "Mail and Newsgroup Account settings"
     --click on the name of the account in question
        --look for a click box, under the signature section called
           "Compose messages in HTML format"

  Configure each account seperately.

HTH,
--Tony

[Jo-hermans (jo-hermans)]

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

[Sb1023 (sb1023)]

Perhaps the problem lies in that Mozilla has the HTML/Plain Text prefs set on a
"per account" basis. Other email clients I have used make this a "global"
setting for all accounts. In Mozilla, if you have an account set for plain text
and want HTML for a message you can do it with CHIFT+COMPOSE. But, there are
times when I'll be in the middle of typing a message and only then realize the
need for HTML formatting. With Outlook Express or Calypso (my current email
client) for example I can just click on a pull-down menu and switch between
Plain Text and HTML "on the fly." With Mozilla, I have to copy my message to the
clipboard, close the compose window, open a new one with the SHIFT+COMPOSE
option, and then paste my message into the new window.

[Public-rudi-2 (public-rudi-2)]

you can switch: PLAIN TEXT --> HTML
but not: HTML --> PLAIN TEXT

Why not: PLAIN TEXT <-> HTML

when I'm in the compose window and when I have already typed in a lot of text!
Like in Comment #10 said there is only the complex way through the Clipboard.

[Malte-6thfloor (malte-6thfloor)]

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.

[Mscott-mozilla (mscott-mozilla)]

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.

[Breaux (breaux)]

Well, the shift-click tip is great! I too was coming to open a Feature request
about this, and I still think it should be added, but that tip will help me in
the meantime. It even works for "Reply"! Now, if only it worked for "Forward",
I'd be a really happy camper. I *definitely* like to switch modes of replies
and forwards pretty frequently.

[Prognathous (prognathous)]

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

Prog.

[Lady-of-dreams (lady-of-dreams)]

"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.

[Prognathous (prognathous)]

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.

[Mcow (mcow)]

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

[Mcow (mcow)]

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

[Ostgote (ostgote)]

see also the corresponding Thunderbird bug 216132

[Mcow (mcow)]

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

[Mcow (mcow)]

The Shift+click is useful for Send and Reply, but doesn't work for Forward; and
there is no way to change formats using Edit As New.

From comment 11 (Rudolf Krist):

> you can switch: PLAIN TEXT --> HTML
> but not: HTML --> PLAIN TEXT

The available switch (Options|Format|Plain Text Only) still leaves you composing
with the HTML font, it's not a true plain-text editor. (Which incidentally
leaves you open to bug 125928.)

As of 1.6, making the switch hides the Format and Insert menus, along with the
format toolbar being hidden. Other than the font, the only visible difference
is whether the Options menu has a Format submenu (HTML) or not (plain).

[Mscott-mozilla (mscott-mozilla)]

moving these bugs to 0.6

[Robert-accettura (raccettura)]

Isn't this more of an editor question?

[Spam-minneboken (spam-minneboken)]

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

[Spam-minneboken (spam-minneboken)]

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

[Mscott-mozilla (mscott-mozilla)]

moving out new feature work

[Sboulema (sboulema)]

Would like to see this button 2 :D

[Bugzilla-mozilla-org-rishichopra (bugzilla-mozilla-org-rishichopra)]

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

[Andreas Krüger (andreas-krueger)]

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

[Andreas Krüger (andreas-krueger)]

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".

[Mscott-mozilla (mscott-mozilla)]

probalby won't make it for 1.0

[Mcow (mcow)]

Moving into more appropriate component.

See also bug 229117.

(In reply to comment #17)
> The Shift+click is useful for Send and Reply, but doesn't work for Forward;

See bug 254931.

[Mcow (mcow)]

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

[Mcow (mcow)]

This is Seamonkey bug 140800.

[Mcow (mcow)]

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

[Jshin1987 (jshin1987)]

(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?

[Jo-hermans (jo-hermans)]

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

[Jeeva (jeeva)]

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

[Stuart Bishop (stub)]

If you start a message in HTML mode, choosing Options->Format->Plain Text Only
switches to plain text mode but the compose window does not switch to a
monospace font. Starting a message in plain text mode uses the correct font.

[Jo-hermans (jo-hermans)]

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

[Tollef Fog Heen (tfheen)]

This is upstream bug 216132 -- https://bugzilla.mozilla.org/show_bug.cgi?id=216132

[Rosenauer (rosenauer)]

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?

[cowwoc (gili)]

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.

[AmitChaudhary (amitch)]

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

[Mcow (mcow)]

(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.

[Vseerror (vseerror)]

(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

[Lady-of-dreams (lady-of-dreams)]

(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.

[Vseerror (vseerror)]

(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?

[Mcow (mcow)]

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.

[Jo-hermans (jo-hermans)]

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

[Ffes (ffes)]

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 :-(

[Mcow (mcow)]

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

[Kaeptn00 (kaeptn00)]

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.

[Bugzilla-ett-idesystem (bugzilla-ett-idesystem)]

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.

[Crys (crys)]

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.

[Bugzilla-ett-idesystem (bugzilla-ett-idesystem)]

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.

[Shijialeee (shijialeee)]

I vote for a button to turn plain text mode on or off.

this is a common feature and i can't believe that it is not easily accessable from the users. plus, the tools->format->plain text only is just rdiculously misleading.

please kill this bug.

[Wkfx2003-bugzilla (wkfx2003-bugzilla)]

I support this feature.
And from the 7 duplicates up to this moment, I think this feature is required by many users

[Carthik Sharma (carthik)]

Thank you for reporting this bug.

Is this still an issue with the latest version of Thunderbird found in Dapper.

Note: the upstream bug linked to appears incorrect, as that is about adding a button to the compose window, and this is about the font not being set right when switching to plain text mode from HTML mode.

[Stuart Bishop (stub)]

I can still reproduce this with the Thunderbird currently in dapper.

The upstream bug looks fine - it seems that the menu item I describe only hides the HTML toolbar and does not actually convert anything at all.

[skierpage (skierpage)]

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.

[Mscott-mozilla (mscott-mozilla)]

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

[Info-markjansen (info-markjansen)]

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

[Mcow (mcow)]

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

[Ryan Kavanagh (ryanakca)]

Thank you for reporting this bug.

Is this still an issue with the latest version of Thunderbird found in Dapper or Edgy?

[Stephanie Daugherty (sdaugherty-deactivatedaccount)]

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

[Brian Murray (brian-murray)]

This is confirmed by Thunderbird's upstream.

[rduke15 (rduke15)]

There seem to be quite a few bug entries revolving around this problem of being able to switch between HTML and plain text.

While I cannot offer a patch to fix it, maybe I can help with a list of the related bugs I came across?

- bug 78794 (Message Compose HTML toolbar is not displayed, when "Edit Message as New")
- bug 130508 (Edit message as new ignores my non-html settings)
- bug 140800 (switch for plain text/html in compose window)
- bug 229117 (Have tabs to toggle between Plain text/HTML modes)
- bug 321784 (add a more visible possibility to compose an HTML message)
- bug 323867 (Allow changing sent plaintext mail to HTML with "Edit As New")

There are many more which are marked as duplicates of one of the above.

[rduke15 (rduke15)]

See also the following related bugs:

- bug 78794 (Message Compose HTML toolbar is not displayed, when "Edit Message
as New")
- bug 130508 (Edit message as new ignores my non-html settings)
- bug 216132 (Toggle mail compose between plain text and html)
- bug 229117 (Have tabs to toggle between Plain text/HTML modes)
- bug 321784 (add a more visible possibility to compose an HTML message)
- bug 323867 (Allow changing sent plaintext mail to HTML with "Edit As New")

One fix could fix them all at once. Too bad I cannot code... :-(

[Moco (moco)]

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

[Sarah Kowalik (hobbsee-deactivatedaccount)]

still an issue in 2.0 from mozilla.org

[James E. LaBarre (jamesl-bestweb)]

(In reply to comment #23)
> (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.

Sorry, just tried this, forwarding a message to another of my email accounts. While it *DID* bring up an HTML formatting window, the mail was sent *plaintext* only. So not only does this not work, it fools you into thinking it does.

So I think it will need to be an intentional override button, just to nudge the programme into realizing it *does* have to do something different with this particular message.

[John Vivirito (gnomefreak)]

How is this upstream bug related? Lp bug is fine its a bug, upstream bug is a wishlist bug to add a radio button to toggle plain text and html. adding a toggle button will not fix this issue
Is this reproducible if you change the font type and restart thunderbird?

[Gary-rumblingedge (gary-rumblingedge)]

Nominating wanted-thunderbird3.

[Rod-whiteley (rod-whiteley)]

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

[Vseerror (vseerror)]

lots of potential dupe material (comment 37 + bug 39854)

[John Vivirito (gnomefreak)]

Is anyone still seeing this issue? If so what version of Thunderbird and what version of Ubuntu are you able to reproduce this bug?

[Andreas Troschka (signupbox)]

Use of HTML/text mode switch is very interesting. Therefore it is not simple to implement in the right way. And what means the right way?
There are some rules to be satisfied:
1. every account should have its default mode to be set through "Account settings"
2. it must be possible to override the default as it is by the use of [shift]+Write/Replay;
3. when Reply is selected, optionally! the editor must open in the same mode as the original Replied e-mail is;
4. if encryption/sign is used, HTML mode must be set with appropriate S/MIME or OpenPGP MIME settings override to ON (so an appropriate variable must be managed to communicate the HTML state to the encryption module);
5....

To answer to those requesting a text/HTML button in the editor window, it seems to be right complicated to do this maintaining the HTML formatting switching to and back from PlainText mode. So the more simple alternative is to set the mode option by selecting PlainText or HTML from a menu' on the Write/Reply buttons like some extension do for other features.
One have to decide the edit-mode for the new message he will write before editing. No later change will be provided.
This will be an efficient way to get the coding simple maintaining the GUI intuitive and userfriendly.

Regards

[Ben Charrow (bcharrow)]

I am still seeing this issue in heron with version 2.0.0.14 (20080505) of mozilla-thunderbird.

[Ben Charrow (bcharrow)]

See http://kb.mozillazine.org/Fixed_width_messages for a fix

[Bugzillamozillaorg-serge-20140323 (bugzillamozillaorg-serge-20140323)]

Filter on "Nobody_NScomTLD_20080620"

[Philringnalda (philringnalda)]

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

[Philringnalda (philringnalda)]

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

[Rsx11m-pub (rsx11m-pub)]

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

[Bryan Clark (clarkbw)]

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

[Xupei-j (xupei-j)]

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! ;)

[Ludovic-mozilla (ludovic-mozilla)]

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

[Philringnalda (philringnalda)]

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

[rusivi2 (rusivi2-deactivatedaccount)]

Thank you for reporting this bug.

Does this occur in Lucid?

[Jo-hermans (jo-hermans)]

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

[Rjesup (rjesup)]

So, we've been duping bug requests against this for 8 years; are we thinking of ever fixing this? This is related to other format bugs like bug 509316 and bug 470062.

I realize solving this 'perfectly' might take a fair bit of work and have tricky constraints - but instead we're not solving it at all. Solve the primary cases and take bugs that it doesn't handle certain edge cases.

To be clear: I'd be happy with basic conversion as if it was sent to an address/domain that's not marked as wanting HTML or as if I'd used 'shift+reply' (which I never found until reading these bugs, which is about as bad as the feature not being there).

This really is an overall design issue about how editing happens and when conversion happens. What I'd state is that the current state is simply badly unsatisfactory for people who ever need to send plain-text messages, as well as being confusing. ("hiding the HTML format bar" (but really still editing in and showing HTML) when selecting plain-text is confusing and surprising to users.)

[Bugzilla2007 (bugzilla2007)]

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

[Bugzilla2007 (bugzilla2007)]

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

[Acelists (acelists)]

Outlook 2007 does have this too.
Going into account settings to enable HTML when needed for one message is quite awkward.

[Mkmelin+mozilla (mkmelin+mozilla)]

Well for one-offs you'd just shift-click write/reply/forward to get the opposite format.

[James E. LaBarre (jamesl-bestweb)]

The shift-click on the "Reply" and "Forward" buttons has been working for me for quite some time now, although it hadn't been even after it was reported elsewhere to be working. So I would expect it *should* work for you at this point (if it doesn't, that could be a different bug)

Of course, getting any new bugs fixed *now* may be more problematic, now that Mozilla has decided to throw the TB developers at the bloated and unstable disaster that is the current-day Firefox.

[Bugzilla2007 (bugzilla2007)]

How is this different from bug 140800?

If they are the same, that would make this quite a much-wanted request with 100 votes and 23 dupes...

[Ws-bugzilla (ws-bugzilla)]

Indeed. Unfortunately Bugzilla does not allow one to merge the votes/dupes, among a thousand other things it doesn't allow, so we'll only get to keep half.

I'm not sure which half to keep, so I'll leave it to someone else to dupe one of the two.

[Mozilla-tlinx (mozilla-tlinx)]

(In reply to Scott MacGregor from 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.

---
Normal protocol would have this newer bug closed as a dup of the older bug.

But the reason I responded to this was about the above comment -- Thunderbird
does a pretty good job of converting HTML structured email to plain text "on the fly"
as it gets sent out (either sent with both text & html or a last minute change to text only).

One fairly simple fix would be to never disable HTML mode -- but put the user in
a default fixed font that wraps ~ around 80 chars. I did 'similar' with a style sheet. Thunderbird handles multiple-level paragraph indent as well as converting
emphasized text to *text* or *TEXT*.. or similar.

So... one could always compose -- even save the dual format locally but on a user desire for text only -- only send the text version.

Important is switching into a mono-font and setting your paragraph wrap width
to your average char width. The CSS method isn't perfect, but it's easy -- and with any hints from the editor about what column you are in so wrapping would
always be right, this doesn't seem like it should be a huge problem.

Isn't there another bug/enhancement about wanting to be able to change style
sheets midway through a compose? This and that might dovetail into something that
solves both...?

[Jim (squibblyflabbetydoo)]

This bug doesn't block basecamp. Basecamp refers to must-have features to launch a B2G-based cellphone, and this wouldn't help much with that.

[Vseerror (vseerror)]

L.A.W. Please find the bug reports of the style sheets and what not you are talking about and post the numbers. thomasd and I are going to whip up some duping and organization this weekend. Thanks

[Mozilla-tlinx (mozilla-tlinx)]

I started to concoct a list -- but realized, it's not really desirable to conflate the bugs I was finding, as they aren't the same bug.

They MIGHT be solved by a well designed solution to this bug. But that wouldn't make them the same bug.

If there was a bug that was about not being to change styles or CSS style sheets
during compose that would be allowed no matter what composition mode you were in,
then some of these bugs might have a dependency on that bug:
Bug 294027 - Need editor event for when message content/style changes
Bug 674184 - HTML Emails sent as Plain Text when no in-message styling
Bug 183219 - <blockquote type="cite"> is nonstandard
Bug 45268 - Add format class to <blockquote type=cite>
Bug 140800 - switch for plain text/html in compose window
Bug 82514 - Change Email Format from Plain Text to HTML cannot show Format Toolbar
Bug 86862 - Message format can't be changed easily
Bug 374196 - Request for Custom Style selection in the Message Compose window for HTML mails
Bug 608660 - Inline CSS styles ignored (possibly single quotes appear)
Bug 691998 - Thunderbird does not create Outlook 2010-compatible HTML emails
Bug 180997 - Inline images or embedded local files silently stripped without trace when force-sending HTML message in plaintext mode (Options > Format > Plain Text only: img lost; need warning and/or conversion into attachments)
Bug 180997 - Inline images or embedded local files silently stripped without trace when force-sending HTML message in plaintext mode (Options > Format > Plain Text only: img lost; need warning and/or conversion into attachments)
Bug 545688 - Allow specifying a CSS style for the quoted text in reply messages
--------------

That's not to say that all of those bugs are even valid -- but that they might be addressed by a well designed solution to this bug, as they all involve how styles are handled, applied, converted, dropped, ignored...etc....

But most of those bugs would definitely NOT be duplicates of this bug.

[Franc Walter (francwalter)]

(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 ;)

[Dmitry Katsubo (dma-k)]

Voting for this issue. Nice to have feature to switch to plain text on-the-fly. Thanks for "Shift+Reply" hint.

[Franc Walter (francwalter)]

This "SHIFT+'Reply'"-hint is better than nothing, but it would be much better if there were ANY way to do this hint WITHOUT the need of the damned mouse.
Even the CommandButtons have no names to catch them at least with AutoHotkey.

[Raman Gupta (rocketraman)]

(In reply to franc from comment #61)
> This "SHIFT+'Reply'"-hint is better than nothing, but it would be much
> better if there were ANY way to do this hint WITHOUT the need of the damned
> mouse.
> Even the CommandButtons have no names to catch them at least with AutoHotkey.

[Raman Gupta (rocketraman)]

> > This "SHIFT+'Reply'"-hint is better than nothing, but it would be much
> > better if there were ANY way to do this hint WITHOUT the need of the damned
> > mouse.

See https://bugzilla.mozilla.org/show_bug.cgi?id=553387

[Bugzilla2007 (bugzilla2007)]

(In reply to Thomas D. from comment #54)
> How is this different from bug 140800?
>
> If they are the same, that would make this quite a much-wanted request with
> 100 votes and 23 dupes...

I have not heard any objections against merging this into bug 140800 as they are essentially the same. That merge definitely needs to happen (but I don't have time right now):

Next Steps for this bug:
* Resolve this bug 216132 as a duplicate of bug 140800, with an explanatory comment asking users to vote for bug 140800 if they want their vote for this bug to be counted (transferring votes)
* Resolve each of the 12 duplicates of this bug 216132 as a duplicate of bug 140800, and also ask users to vote for bug 140800 if they so wish (transferring duplicates)

[Bugzilla2007 (bugzilla2007)]

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

[Sebastian W. (yodamin)]

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?

[Sebastian W. (yodamin)]

Most of you probably saw this mesage, but as we have several bugs here is it again:

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=140800 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?

[Bugzilla2007 (bugzilla2007)]

Hi! You are receiving this message because you are cc'ed on Thunderbird's Bug 216132: Toggle mail compose between Plain text and HTML. As announced in comment 65, and in support of weirdkeen's most welcome initiative to finally tackle this bug (see comment 67), I'm duping this bug against bug 140800, which is the very same request per its current summary and content ("switch for plain text/html in compose window").

This bug 216132 currently has 52 votes (and 59 votes on bug 140800). Unfortunately bugzilla does not allow merging of votes along with duping, therefore:

-> PLEASE VOTE FOR BUG 140800 NOW so that your vote can be transferred to and counted for bug 140800.
To vote, click on the link [1] below, ensure the checkbox for bug 140800 is ticked and don't forget to confirm your vote with "Change My Votes" button at the bottom of your personal votes page. Tia.

[1] https://bugzilla.mozilla.org/page.cgi?id=voting/user.html&bug_id=140800#vote_140800

Fyi, you'll probably be aware that TB is now maintained mostly by the volunteer community, so we need your help to keep TB going. Can you help in any of the following areas?
- bug triaging
- bug fixing
- documentation
- translation
- etc.

---------------------
(In reply to Thomas D. (away till 31st January) from comment #65)
> (In reply to Thomas D. from comment #54)
> > How is this different from bug 140800?
> >
> > If they are the same, that would make this quite a much-wanted request with
> > 100 votes and 23 dupes...
>
> I have not heard any objections against merging this into bug 140800 as they
> are essentially the same. That merge definitely needs to happen (but I don't
> have time right now):
>
> Next Steps for this bug:
> * Resolve this bug 216132 as a duplicate of bug 140800, with an explanatory
> comment asking users to vote for bug 140800 if they want their vote for this
> bug to be counted (transferring votes)

done.

> * Resolve each of the 12 duplicates of this bug 216132 as a duplicate of bug
> 140800, and also ask users to vote for bug 140800 if they so wish
> (transferring duplicates)

still to be done, plus check for "dupes of dupes" and also re-dupe them to bug 140800.

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

[Bugzilla2007 (bugzilla2007)]

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

[Bugzilla2007 (bugzilla2007)]

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.

[Bugzilla2007 (bugzilla2007)]

(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! :)

[Mkmelin+mozilla (mkmelin+mozilla)]

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.

[Bugzilla2007 (bugzilla2007)]

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

[Najoll (najoll)]

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.

[Drghughes (drghughes)]

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.

[Jorg K (jorgk)]

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).

[Bugzilla-kabsi (bugzilla-kabsi)]

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.

[Jorg K (jorgk)]

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.

[Jorg K (jorgk)]

> 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.

[Bugzilla-kabsi (bugzilla-kabsi)]

(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. ;-)

[Jorg K (jorgk)]

(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.

[Bugzilla-kabsi (bugzilla-kabsi)]

(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".

[Jorg K (jorgk)]

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.

[Bugzilla-kabsi (bugzilla-kabsi)]

(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.

[Jorg K (jorgk)]

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.

[Acelists (acelists)]

(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.

[Bugzilla-kabsi (bugzilla-kabsi)]

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?

[Jorg K (jorgk)]

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.

[Bugzilla-kabsi (bugzilla-kabsi)]

(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.

[Jorg K (jorgk)]

(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.

[Jorg K (jorgk)]

Could be some Google Summer of Code project.

[Maf-soft (maf-soft)]

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

[Mikeweilgart (mikeweilgart)]

(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?

[Bugzilla2007 (bugzilla2007)]

(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...

[Bugzilla2007 (bugzilla2007)]

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

[Mikeweilgart (mikeweilgart)]

(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.

[Jorg K (jorgk)]

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

[Infofrommozilla (infofrommozilla)]

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

[Infofrommozilla (infofrommozilla)]

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

[Aaron Wolf (wolftune)]

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.

[Aaron Wolf (wolftune)]

(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.