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)
Thunderbird
Message Compose Window
Tracking
(Not tracked)
RESOLVED
DUPLICATE
of bug 140800
People
(Reporter: mscott, Unassigned)
References
(Depends on 1 open bug, 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.
Reporter | ||
Updated•21 years ago
|
Status: NEW → ASSIGNED
Target Milestone: --- → Thunderbird0.3
Comment 1•21 years ago
|
||
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.
Reporter | ||
Comment 2•21 years ago
|
||
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.
Reporter | ||
Updated•21 years ago
|
Target Milestone: Thunderbird0.3 → Thunderbird0.5
Updated•21 years ago
|
QA Contact: asa
Comment 3•21 years ago
|
||
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.
Comment 5•21 years ago
|
||
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.
Reporter | ||
Comment 6•21 years ago
|
||
moving these bugs to 0.6
Target Milestone: Thunderbird0.5 → Thunderbird0.6
Reporter | ||
Comment 8•21 years ago
|
||
moving out new feature work
Target Milestone: Thunderbird0.6 → Thunderbird0.8
Comment 11•21 years ago
|
||
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
Comment 12•21 years ago
|
||
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".
Reporter | ||
Comment 13•21 years ago
|
||
probalby won't make it for 1.0
Target Milestone: Thunderbird0.8 → Thunderbird0.9
Comment 16•20 years ago
|
||
(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?
Reporter | ||
Updated•20 years ago
|
Target Milestone: Thunderbird0.9 → Thunderbird1.1
Reporter | ||
Updated•20 years ago
|
Target Milestone: Thunderbird1.1 → Thunderbird1.5
Comment 20•20 years ago
|
||
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?
Comment 21•20 years ago
|
||
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.
Comment 22•20 years ago
|
||
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
Comment 23•20 years ago
|
||
(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.
Comment 24•20 years ago
|
||
(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
Comment 25•20 years ago
|
||
(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.
Comment 26•20 years ago
|
||
(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?
Comment 27•20 years ago
|
||
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.
Comment 29•19 years ago
|
||
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 :-(
Comment 30•19 years ago
|
||
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.
Comment 31•19 years ago
|
||
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.
Updated•19 years ago
|
Flags: blocking-thunderbird2?
Comment 32•19 years ago
|
||
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.
Comment 33•19 years ago
|
||
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.
Comment 34•19 years ago
|
||
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.
Updated•18 years ago
|
QA Contact: message-compose
Comment 37•18 years ago
|
||
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.
Comment 38•17 years ago
|
||
(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.
Updated•17 years ago
|
Severity: normal → enhancement
Comment 42•17 years ago
|
||
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
Updated•16 years ago
|
Assignee: mscott → nobody
Status: ASSIGNED → NEW
Updated•16 years ago
|
Hardware: PC → All
Updated•15 years ago
|
Target Milestone: Thunderbird 3 → ---
See Also: → https://launchpad.net/bugs/10883
Comment 49•13 years ago
|
||
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.)
Comment 51•12 years ago
|
||
Outlook 2007 does have this too. Going into account settings to enable HTML when needed for one message is quite awkward.
Whiteboard: [parity-Outlook]
Comment 52•12 years ago
|
||
Well for one-offs you'd just shift-click write/reply/forward to get the opposite format.
Comment 53•12 years ago
|
||
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.
Updated•12 years ago
|
Flags: wanted-thunderbird3?
Comment 54•12 years ago
|
||
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...
Comment 55•12 years ago
|
||
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.
Comment 56•12 years ago
|
||
(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: --- → ?
Comment 57•12 years ago
|
||
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: ? → ---
Comment 58•12 years ago
|
||
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
Comment 59•12 years ago
|
||
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.
Comment 60•11 years ago
|
||
Voting for this issue. Nice to have feature to switch to plain text on-the-fly. Thanks for "Shift+Reply" hint.
Comment 61•11 years ago
|
||
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.
Comment 62•11 years ago
|
||
(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.
Comment 63•11 years ago
|
||
> > 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
Comment 64•11 years ago
|
||
> > 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
Updated•11 years ago
|
Blocks: HTML-compose-tracker
Updated•11 years ago
|
Blocks: delivery-format-ux
Comment 65•11 years ago
|
||
(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: 140800
Comment 67•11 years ago
|
||
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?
Comment 68•11 years ago
|
||
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
You need to log in
before you can comment on or make changes to this bug.
Description
•