Closed Bug 216132 Opened 21 years ago Closed 11 years ago

Toggle mail compose between plain text and html

Categories

(Thunderbird :: Message Compose Window, enhancement)

Product:
Thunderbird
Component:
Message Compose Window
Type:
enhancement
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

Status:
RESOLVED DUPLICATE of bug 140800

People

(Reporter: mscott, Unassigned)

References

(Blocks 2 open bugs)

Details

(Keywords: helpwanted, Whiteboard: [parity-Outlook]) 

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

What would be useful when implementing this: selecting the account from compose
window ("From:" drop-down) should active the respective default composing mode
(HTML or plain text) for that account.
Options / Format just shows and hides the HTML toolbar, your HTML content is
left in tact. What I'm envisioning is an actual converter. If you toggle into
plain text editor, we lose all of the HTML and conver the live message body into
plain text.
Target Milestone: Thunderbird0.3 → Thunderbird0.5
QA Contact: asa
I would also like to suggest that the last setting would persist for future
composed emails.

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

Prog."

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

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

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

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

Prog.
moving these bugs to 0.6
Target Milestone: Thunderbird0.5 → Thunderbird0.6
Isn't this more of an editor question?
moving out new feature work
Target Milestone: Thunderbird0.6 → Thunderbird0.8
Would like to see this button 2 :D
ditto; cheers to Scott if he can see this through.
I would also like to see this functionality,
and would like to see it made available through the "Options" top-level menue.

Suggestion:

Options ->
  Format... ->
    Plain Text
    HTML
It may be worth it to provide the functionality under a consistent/single
GUI-umbrella for the following three bugs:

This bug, bug 229462, bug 227265.

In each of theses cases, the issue is an instance of
"change global state for the one message being composed".
probalby won't make it for 1.0
Target Milestone: Thunderbird0.8 → Thunderbird0.9
*** Bug 245659 has been marked as a duplicate of this bug. ***
This is Seamonkey bug 140800.
(In reply to comment #5)
> Lisa. comment #4: 
> > ...my sense is that most users use that prefered format 95% of the time, 
> > and that changing the format is often an isolated occurrence

  My usage pattern is like what you described. 99% of time, I write in plain
text, but once  in a while, I send html or multipart/alternative so that I don't
want this to be persistent.
 
> That means that 95% of the time, you won't have to change anything. The
> advantage of making this option persistent is that we don't have to add yet
> another pref to the already packed-to-the-brim preferences panels.

 Don't we already have that pref per mail server?
Target Milestone: Thunderbird0.9 → Thunderbird1.1
*** Bug 268461 has been marked as a duplicate of this bug. ***
When will we have this? 
IMHO, this is one of the most important feature.
*** Bug 275969 has been marked as a duplicate of this bug. ***
Target Milestone: Thunderbird1.1 → Thunderbird1.5
Just needed this feature as well - didn't Mozilla Mail have this option already?
I just needed to send an article from a non-public webpage to a colleague so
sending the link was not possible. This is where HTML-mail is really useful 
(i.e. 1% of all cases;)

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

Will this feature make it into 1.0.1?
I totally want this feature. I keep on getting **** HTML-format messages with
tiny fonts and bad colors. I expect that when I change the format to "plain
text" that Thunderbird should convert the message right away. Right now it just
hides the HTML toolbar (like you mentioned above) but this is useless to me. I
want the message converted immediately when I change to plain text.
I would like this feature too. I use multiple accounts using global local
folders (one inbox) in thunderbird and use plain text as a default.

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

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

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

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


But that's just a workaround.  It would of course be more flexible if there were 
a way to toggle the compose mode once the compose window has opened.  One 
drawback is that toggling from HTML mode to plain mode will lose any formatting 
(per Scott's comment 2), and if you toggle accidentally, toggling back will give 
you just the basic conversion without restoring the formatting.  I suppose it 
could be made Undo-able.
(In reply to comment #21)
> I totally want this feature. I keep on getting crappy HTML-format messages with
> tiny fonts and bad colors. 

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

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

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


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

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

quite right - my bad

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

Then, as long as the shift+tool hack is being relied on, Shift+Forward would 
reverse the expectation; and when/if the in-window mode-switch is in place, the 
original HTML information shouldn't be lost on a forward unless the user 
explicitly forced it.  However, per bug 293649, there is some *other* problem 
with Forward Inline where at least some formatting is getting discarded even 
when the compose window is HTML.
*** Bug 298002 has been marked as a duplicate of this bug. ***
There is a extension that gives you the option to choose the format when
replying. It is not a full solution for this bug, but it helps a bit.

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

On small problem though, does not work yet with 1.5b1 :-(
OS: Windows XP → All
My two pennies ...

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

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

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

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


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

That setting could be set by a prompt that shows up when the user has replied and immediately changed to the other format a few times.  For example: "Do you want to save a preference to always use plain text format when writing email? Yes/No".  But now we're getting fancy.  Just being able to change format would be great!  Thanks.
Flags: blocking-thunderbird2?
I agree with the Toggle. In Evolution on Linux this happens wonderfully. I don't know how it remembers, but I have it set to create email in plain text by default. If I reply to or forward an HTML mail, it initially does it as plain text (strips the html out), but if I go to Format->Html, the HTML reappears like magic. 

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

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

Forward is more or less useless in TB.  Until forward is fixed, you can click "reply" and change the "Re:" to "Fw:", and manually edit the recipients list.  There are all kinds of problems with "forward", ranging from crummy formatting (read: different from when replying to the same email), to inline images that don't get sent and TB crashing.
I thought that Options > Format > Plain Text Only is this toggle and is simply utterly broken -- it only changes your message to plain text when you Send or Send Later.  So I filed bug 339887.  If Options > Format is not intended to do what this bug requests then there should be a separate bug that it is very confusing and should be renamed, e.g. Options > **Message Delivery Format** > Plain Text Only.

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

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

I'm not going to get to this for 2.
Flags: blocking-thunderbird2?
Keywords: helpwanted
Target Milestone: Thunderbird1.5 → Thunderbird 3
Please also consider the comments in bug-ID 321784 regarding this issue
QA Contact: message-compose
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.

(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.
Severity: normal → enhancement
Nominating wanted-thunderbird3.
Flags: wanted-thunderbird3?
lots of potential dupe material (comment 37 + bug 39854)
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
Assignee: mscott → nobody
Status: ASSIGNED → NEW
Hardware: PC → All
Target Milestone: Thunderbird 3 → ---
See Also: → https://launchpad.net/bugs/10883
Blocks: 553387
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.)
Outlook 2007 does have this too.
Going into account settings to enable HTML when needed for one message is quite awkward.
Whiteboard: [parity-Outlook]
Well for one-offs you'd just shift-click write/reply/forward to get the opposite format.
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.
Flags: wanted-thunderbird3?
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...
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.
(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...?
blocking-basecamp: --- → ?
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.
blocking-basecamp: ? → ---
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
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.
Voting for this issue. Nice to have feature to switch to plain text on-the-fly. Thanks for "Shift+Reply" hint.
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.
(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.
> > 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
> > 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
(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)
Depends on: text-html-switch
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?
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.
Status: NEW → RESOLVED
Closed: 11 years ago
Resolution: --- → DUPLICATE
No longer depends on: text-html-switch
You need to log in before you can comment on or make changes to this bug.