
How to edit HTML when composing an email
I recently upgraded to version 60 from (I think) 58 something. Now there is no HTML tab above the body of the email and I can find no way to get into the HTML. Why has this gone away or, if it hasn't gone away, how do I get to it?
Chosen solution
If you had an 'HTML tab' in the Write window, it was provided by an add-on, which may have worked in earlier versions but perhaps not in TB 60. The old add-on might work if you change the preference extensions.strictCompatibility to false in Tools/Options/Advanced/General/Config. editor (double-click a pref. to toggle the value).
The EditHTML add-on works in TB 60; show it by selecting Format/Edit HTML in the Write window.
You can always edit the HTML by selecting the message body then Insert/HTML...
Read this answer in context 👍 1All Replies (15)
I forgot to add that in the Composition tab in Account Settings, "Compose messages in HTML format" is checked.
Chosen Solution
If you had an 'HTML tab' in the Write window, it was provided by an add-on, which may have worked in earlier versions but perhaps not in TB 60. The old add-on might work if you change the preference extensions.strictCompatibility to false in Tools/Options/Advanced/General/Config. editor (double-click a pref. to toggle the value).
The EditHTML add-on works in TB 60; show it by selecting Format/Edit HTML in the Write window.
You can always edit the HTML by selecting the message body then Insert/HTML...
Get the HTML editing tab back:
https://addons.thunderbird.net/en-US/thunderbird/addon/thunderhtmledit/?src=cb-dl-toprated
The add-on author claims TB60 compatibility. If there is a problem, change strict compatibility from true to false, as detailed above.
The thunderhtmledit add-on is feature rich and markedly superior to the EditHTML add-on, imho...
Modified
Here is a new problem with TB 60. Since the upgrade from the former version, an extra string is added to the HTML-code. If you use the Ctrl+A and then go Insert > HTML... ...and then you may make a small change, like correct a spelling error. Then you insert the HTML and save the email. Open it again and look at the HTML-code. ...you will then notice, that this: & # x A ; has been added to the codes. Every time you edit HTML and save the draft, more strings get added. It could for instance look like this: (sorry, it's not possible to enter html code in this form, it disappears, so I'll add some spaces to make it look like text)
t a b l e s t y l e=" f o n t-s ize: 12p x; f ont-f amily: V erdana, & # x A ; & # x A ; & # x A; Ar ial,; & # x A ; & # x A ; & # x A ; Helve tica;"
This did not happen before TB 60. It's a huge problem, if you make several changes, as you alwasy do, if you write a newsletter.
Modified
Heine said
Here is a new problem with TB 60. Since the upgrade from the former version, an extra string is added to the HTML-code. If you use the Ctrl+A and then go Insert > HTML... ...and then you may make a small change, like correct a spelling error. Then you insert the HTML and save the email. Open it again and look at the HTML-code. ...you will then notice, that this: & # x A ;
I can't reproduce this in TB 60.3.1 on W10. The & # x a ; is apparently a line feed character. Is this on Linux? I can't explain why it appears in your html code.
Modified
It's on Windows 10 in 64-bit. And TB 60.3.1 in 32-bit. I don't see, how an external program could cause this. Could it be a setting in TB, that I changed? It's just a but strange, that I occured right after TB upgraded (and now look a bit different).
You have to open and see the mail as HTML with codes and everything, then save, close the email and open it again.
I've tried it by saving, closing and opening again, and there is no addition of the line feed character. This is with a message whose html code is created only by the TB message composer.
As a first step, I would Help/Restart with Add-ons Disabled and see if the behaviour persists.
I tried to restart with add-ons disabled. Maybe I can mail you an example? The emails in question include tables and formatting for fonts. Send a mail to hs@indigo2.dk, and I will mail you and example and you should know, that I am gratefull for your time and interest.
Heine
Heine: I am also unable to reproduce the problem. Windows 10 and TB 60.3.1. What happens if you instead make the html edit using the thunderhtmledit add-on?
Well, ThunderHTMLedit is the reason I found out about this problem in the first When ThunderHTMLedit is not activate, I can open an email for edit and close it again "with no questions asked" if I have made no changes to the email. If ThunderHTMLedit is active, and I do the same, then a box pops up and asks, if I want to save the changes or not - even though no changes was made by me. I then deactivated ThunderHTMLedit, and instead I used the build in function "Insert > html..." I get the same pop-up asking me to save the changes or not, if I have opened the html-window and closed it again with no changes made. Is it possible to go back to the previous version of Thunderbird?
Heine: If I follow you, just opening an html window and then closing it with no edits still adds code to your email and you are prompted about saving the changes. This is happening for you both with the add-on and with TB's native html editor. I hope sfhowes can take a look - very mysterious.
Thanks everybody. It's getting more mysterious, but also more specific, so I would think a person who knows more about the underlying "motor" i TB should be able to figure out, what's wrong.
1. The problem is with TB 60.x.x, not with 52.9.1, that I just installed. Or maybe TB 52 just doesn't show these linefeed commands & # X a ;
2. TB 60 has this problem only with emails that includes tables. I also get these extra linefeed characters in many commercial emails, that I have received from others, but only if they have tables. Not all emails with tables have the problem, so some must comply better to the "TB-standard" than others.
3. just opening one of my own emails with tables and closing it again prompts for Save or Cancel. If one of these emails have been sent to someone, who answers me back, with the original email included, then I can open the email and close it without being prompted to save it. The email still contains the line feed codes though, and if I actually save the mail, the line feed codes will be doubled.
3. If an email has says 20 of these erroneous codes for line feed, then it will have 40 after saving it. Opening it and saving it again, it will end up with 60 (not 80, so not double).
4. TB 52.9.1 doesn't show any line feed codes, not even in mails, that had hundreds of them when examined in TB 60. Either TB 52 cannot show them, or they get filtered out. I opened an email that had these line feeds, when I looked at it in the TB 60 editor, and there were no line feed codes in the editor of TB 52. When I saved the email from TB 52, it shrunk from 17 kb to 10 kb. The difference is much larger than the number of line feeds could account for, so maybe this is not significant.
With more systematic testing, I could probably narrow it down, but I think at this point maybe someone with more technical expertise can come up with an idea. I will stick with TB 52 for a while, but in the long run it's not sustainable.
It boils down to this: the tags should be made in TB with it's own formatting tools. I used my own styles to get around design problems, and TB does not cope well with this.
PS: a really annoying thing: drafts, that were edited with TB 60, and are now edited with TB 52, will produce en new draft every time it is saved instead of overwriting the old draft. It's like saving templates, where you have always has a new file for each save.
Modified
Heine: Part way there. For any email with a table, if I open the email in the html editor, I am prompted to save changes even if I have made no edits. BUT when I then reopen the same email in the html editor there are NO added line feeds or other characters.
I also wrote about this at bugzilla.mozilla.org One of the technically minded persons there found that the problem occurs when tags are broken across lines.
Most likely we're looking at a Core::Editor bug here that the Mozilla team will need to fix. It's not limited to tables, it happens for all tag attribute strings broken across lines.
We have a very valuable contributor who can find where a problem started occurring, so for him we need very simple steps to reproduce the problem.
So here goes. STR:
Create a new HTML message. Click into the body. Form the menu: Insert > HTML. Insert this: < d i v s t y l e="font-size: 12px; font-family: Verdana,
Arial, Helvetica;">
</di v> Save the message as draft, inspect the message source.
Bad: <d iv st yle="fon t-siz e: 12p x; fon t-fami ly: Verda na,& #x A; Ar ial,
Helve tica;">
</di v> Notice the unwanted & # x A;
The unwanted & # x A; is fixed in TB 60.3.2:
https://www.thunderbird.net/en-US/thunderbird/60.3.2/releasenotes/