802190 - Thunderbird changes fonts and font sizes while moving between lines

Status: RESOLVED DUPLICATE of bug 756984

(Thunderbird :: Message Compose Window, defect)

Description

[Joris Debonnet]

User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:15.0) Gecko/20100101 Firefox/15.0.1
Build ID: 20120905151427

Steps to reproduce:

Try to type an email, without having to worry about anything. 


Actual results:

Thunderbird changes fonts and font sizes while moving between lines. These are perhaps the main issues, but there are others as well.


Expected results:

To be honest, I very much vouch to redo the composer. The WYSIWYG editor is... well, not anywhere near sufficient. There are a lot of nuisances. 

I truly love using Thunderbird, I haven't used another mail client since it was released. Most things work fine, but the composer... breaks it down. It is below the quality of the rest of the application. 

Others with the same issue: 
https://getsatisfaction.com/mozilla_messaging/topics/enhanced_html_editing_composing_for_thunderbird

An addon that uses CKEditor, but which is sadly not maintained: 
https://addons.mozilla.org/en-us/thunderbird/addon/compose-for-thunderbird/
This addon looks extremely promising. Is there no way you would consider finishing its development? 

I've read the news release about Thunderbird stopping further innovation, but I really hope this can be an exception. The composer pulls the rest of the appliation down, and makes people consider leaving it for another email client.

Comment 1

[Mark Banner (:standard8)]

Please can you include some exact steps for reproducing your issues. Without those, it will be very difficult for us to resolve your issues.

It would also be useful to know if you can reproduce your issue on http://www-archive.mozilla.org/editor/midasdemo/

Comment 2

[Joris Debonnet]

I will do my best, although there are so many little bits that I was actually just suggesting to redo the whole thing, more like a feature request (or what would you call it) than a bug report I guess. 

The issue is that the Thunderbird composer is basically a plain text editor with some extra's. It is not at the same standard as other rich text editors. Some comments on the getsatifscation.com link I posted above suggest editors that could be incorporated into Thunderbird.

Concerning Mozilla products, I read some things about SeaMonkey and Kompozer. Perhaps those is a way to go? 


Onward to the issues:

1. (also works on midasdemo) Forgetting font at the end of a line.
1.1. Write a line and then a few linebreaks. 
1.2. Select that first line (select from left to right, or from 'home' to 'end' of the lind)
1.3. Use the dropdown to change the font to, for example, Arial. 
1.4. Move away, for example because you're typing something somewhere else. 
1.5. Move back to the end of that first line, and add something to it. 
===> The added text is not in Arial. That's because the cursor is placed after </font>. 
Solution: whenever a line selected going all the way to the right, include the <br> there. That way, </font> appears in the next line, so that adding text on the first line will always be in the same font. In some editors, this will visually look like you've selected an additional space at the end, though actually it's the linebreak you've selected there.

2. Color: exactly the same issue as 1. 

3. Font size
This is almost exactly the same as 1., except that midasdemo correctly places the </font> after the <br> so that added text is also small. Thunderbird does not do this: adding text to a small-text line will put it in the original font. 

4. CSS and the <font> tag
Actually, the <font> tag is no longer needed, even for html email. As long as all css is put inline, and it doesn't get too complicated, it works perfectly everywhere. Adopting a more css oriented approach will probably also avoid silly situations like <big><font face="arial"><font color="green"><small>This is some text!</small></font></font></big> in the future. 

5. Lists
The composer ends all <font> tages before the <ul> tag, and then opens them again for each li. As a result, you can't color the bullet points. I realise this may have something to do with the <font> tag not technically being allowed to contain <ul> tags,... but the used HTML is currently outdated anyway. If you'll stick with <font> tags, I would vouch to ignore this limitation, because every email client I know of renders an <ul> inside a <font> correctly anyway. In the other case of course, css based email would fix this and a lot of other things. 


These are my personal main issues. I could go on for a while though:
6. A "Source" button would be handy. The only way to edit source is to select the entire email and go to Insert > HTML. 
7. "Insert > HTML" feels a bit useless, unless you select all text. Try using it: suppose you have some text in Arial, and then you want to insert <i>italic</i> in the middle. It won't be in Arial, because Thunderbird makes the inserted HTML into a little island with no inherited style.
8. Intelligent word spacing when dragging words. Example: "One two three." Select and move 'three' before 'two', and it will become "One threetwo ." instead of the desired "One three two." This is a trickier issue though, because most editors in fact don't do this correctly. It can be partly fixed by selecting the space on the left of the word, in case no space is to be found on the right. Also, if the destination drag point is just before or after a space, the dragged word should intelligently be placed on the correct side of the space so that no two spaces end up next to each other (and no words are stuck to each other after dragging). 


There are other issues that I either can't think of or find difficult to explain. I'll leave it to this for now. 

I really believe it would be interesting though if you read https://getsatisfaction.com/mozilla_messaging/topics/enhanced_html_editing_composing_for_thunderbird . I admit the atmosphere is a bit negative there, but some people make some good suggestions. At the least, it proves that this is an important point.

Comment 3

[Joris Debonnet]

Here are two more issues I thought of in the meanwhile: 

9.1. Start a new email, with a default font for example Arial. 
9.2. Type a few words, then reconsider and delete everything you wrote. 
9.3. Start writing again: the font is no longer in Arial (even though the dropdown still shows that as selected). 

10. Very similar: create a list with items inside a block of Arial text, then the list items will also be Arial. However, when you delete the contents of a list item and want to replace it with something else, the formatting is lost.

Comment 4

[Joris Debonnet]

There's also a relatively new problem that I didn't have before: emails not being sent the way they looked when I was editing it. That's only since a few versions ago, perhaps since version 15. 

My default font is Verdana, Small (it's too big on Medium). Two hours ago, I sent an email to someone. This is my first sentence, without any special markup:

Supposedly every Dane has heard about it: the story of Carina. Perhaps you haven't though, since you're only back there for a week. 

This is what this line was apparently sent as, in HTML: 

<font size="-1"><font size="-1">Supposedly every Dane has <font size="-1">hear<font size="-1">d about it: the stor<font size="-1">y<font size="-1"> of Carina. Perhaps you haven't thoug<font size="-1">h, since you're <font size="-1">only back there for a week. </font></font></font></font></font></font></font></font></font></font></font>

Even though that's crazy, it displays correctly. It's just being (very) redundant. Probably while I'm making small edits while I review my email, but that still shouldn't happen, right? I can reproduce it by just writing multiple lines of gibberish (in my standard -1 size font), and then going back in the middle of the text and replacing parts. 

A more serious problem is the following: the rest of that email was - as far as I could see - in the same font (verdana small). But when I got a reply I could see this was not the case, and in my Sent folder I could confirm that it was sent differently: the rest of my email is not Verdana (but 'standard font'), and at one point the font size also jumps up and then goes down again a bit later. I also see a lot of indenting in the html code, and the last line of my email (before </body</html>)is: 
                                                </font></font></font></font></font></font></font></font></font></font></font></font></font></font></font></font></font></font></font></font></font></font></font>


This is something I'm not used to - it didn't happen in the past. Might it be a side effect of a recent patch in version 15?

Comment 5

[Joris Debonnet]

Perhaps my list of issues is a bit chaotic and intimidating. If completely redoing the HTML editor is not an option, would it be better if I created a few separate bug reports for the most important issues? At this time, the most annoying one for me personally is that What Is See is not What I Get. So perhaps I should make a shorter and clearer bug report for that, instead of waiting for a reaction here?

Comment 6

[capka]

This is an endorsement to comment #4 above - I've observed the same strange font appearance in composition and the same multitude of <font size="-1"> elements in the resulting html messages. Recipients have confirmed odd font changes when displayed in their readers. I reverted to v15.0.1 because this behavior was making composition under 16 too painful.

Comment 7

[Joris Debonnet]

I've just now also decided to revert to 15.0.1, and the problem indeed doesn't happen there. I should have done this much earlier - but it's just strange that not lots of other people are reporting such annoying bahavior. I checked a few other bugs: 798868 and 782215 are probably related. Comment #7 on 782215 has a reproducible scenario of exactly this problem.

Comment 8

[maybe-the-one]

"...it's just strange that not lots of other people are reporting such annoying behavior."

Everyone using html format sees it; we've just given up on Mozilla ever doing anything about it.

Where do we get v 15, and can our profile be moved into it with Mozback?

Comment 9

[Joris Debonnet]

One of the places you can download Thunderbird 15 is oldapps.com: 
http://www.oldapps.com/thunderbird.php?old_thunderbird=8203

But I don't think MozBackup can migrate profiles from newer versions to older versions... haven't tried it though. 

I'm still using Thunderbird myself (latest version), as it's the only email client I have ever used, but I'm starting to consider moving to Outlook :| which is a very sad thing because I strongly dislike that client. I love Thunderbird much more, all parts work perfectly fine as far as I'm concerned - but that excludes the compose window which drags it all the way down. Feels quite wrong to have an email client that includes a range of useful and well laid out features, but that you can't comfortably send emails with. Somehow I think that ought to be a priority for an email client. 

I realise all this text is not very fitting for a bug report, but as I mentioned a few years ago here, this is rather a call to redo the whole composer (starting from a wysiwyg editor that works well), rather than reinvent the wheel. Because with the limited manpower Thunderbird now has, the composer will never be up to par with wysiwyg editors that have stronger support. I realise redoing the composer is a very daunting task, but if Thunderbird is to survive (is it?), I feel like it is the only good way forward. It's a large investment now in order to be able to profit from the external editor support later (if all the Thunderbird hooks and stuff are added in a modular way).

Comment 10

[Wayne Mery (:wsmwk)]

(In reply to maybe-the-one from comment #8)
> ... can our profile be moved into it with Mozback?

You do not need to do anything with your profile

No doubt this is frustrating. Unfortunately it won't be fixed until someone with the skills and time to fix it is found. It does not currently exist among the current crop of Thunderbird developers, most or all of whom have no experience in the editor code, which is shared with and primarily maintained by Firefox folk. So now you have the full picture.

Comment 11

[Joris Debonnet]

I shall have to think long and hard about whether to commit to working on this myself... I'm a software engineer, but of course (just as for anyone) days are busy enough already :) I may revisit this in the future.

Comment 12

[Jorg K (CEST = GMT+2)]

Clear duplicate of bug 756984, see comment #2:
> 1.5. Move back to the end of that first line, and add something to it.
Fixed in TB 38.

There's been some discussion lately on "losing font" issues, see bug 677046 comment #30 and bug 677046 comment #32.

If someone can give clear steps to demonstrate another problem, they should file a new bug.