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 aewell@gbis.com

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

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

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

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.

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.

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.

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

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

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

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.

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.

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.

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

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

see also the corresponding Thunderbird bug 216132

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

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

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

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

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.

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

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

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.

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

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

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

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

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

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.

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 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. +1 > Can someone point at the specific source code file(s) where such a feature > would likely live? The UI lives here (XUL, Mozilla's outphasing XML/HTML flavor for UIs): https://dxr.mozilla.org/comm-central/source/mail/components/compose/content/messengercompose.xul A lot of respective code lives here (javascript): https://dxr.mozilla.org/comm-central/source/mail/components/compose/content/MsgComposeCommands.js If you just imitate the way other similar commands are set up between XUL and javascript, there's a good chance to get this part right. Some of the deep stuff code may live here (this is the harder part, depending on how this will be implemented; C++): https://dxr.mozilla.org/comm-central/source/mailnews/mime/src/mimedrft.cpp

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.