Closed Bug 250539 Opened 20 years ago Closed 12 years ago

New paragraph (e.g. list) clears formatting, does not respect font prefs for HTML messages

Categories

(MailNews Core :: Composition, defect)

Product:
MailNews Core
Component:
Composition
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

(blocking-thunderbird3.1 -)

Status:
RESOLVED FIXED
Milestone:
Thunderbird 15.0
Tracking Flags:
Tracking Status
blocking-thunderbird3.1 --- -

People

(Reporter: assafu, Unassigned)

References

(Blocks 1 open bug,
URL
)

Details

(Whiteboard: [fixed by bug 590640][see comment 259 - file NEW bugs for other issues][gs])

Attachments

(2 files)

tentative fix for the list issue
3.51 KB, patch
Details | Diff | Splinter Review
different approach
627 bytes, patch
Details | Diff | Splinter Review 
User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040206 Firefox/0.8
Build Identifier: version 0.6 (20040502)

If you set your HTML Options to Helvetica/Arial small and start typing a
message, and then create a bulleted list, the font changes to Variable Width
Medium and remains that way.

Reproducible: Always
Steps to Reproduce:
1. Go to Options -> Composition -> Html Options... and set font to
Helvetica/Arial  Small
2. Compose a new message
3. Begin typing (should be in Arial Small), hit return, and click on the
bulleted list icon.


Actual Results:  
The font changes to Variable Width/Medium, and stays there after you finish the
bulleted list.

Expected Results:  
The font should have remained at the default setting even for bulleted lists.
This is true for any change in 'paragraph style' on an empty line -- text where 
the cursor is directly between two <br> tags, or between <p> and </p>.  Any 
action which inserts a new paragraph style -- lists, indent or outdent, or 
changing a line of body text into a <p> -- on an empty line will discard any 
text formatting from the current text.

This behavior is also seen in the Composer (for HTML documents), but in that 
case, there are no "preferences" to fall back on, so it's arguable 

Part of the problem is that the font family and size, and local text color as 
well, is implemented using <font> tags rather than CSS.

Workaround: Before inserting the list, type (some) text for the first bullet 
item.  Put the cursor on that line (or select the line), and then click the 
Bullet List button -- the newly created list will maintain the text on the item, 
and on subsequent items as well.

This bug exists in Seamonkey as well.  I couldn't find a dupe under Mail/News, 
nor under any of the Browser:Editor bugs.
Status: UNCONFIRMED → NEW
Component: Message Compose Window → Composition
Ever confirmed: true
OS: Windows XP → All
Product: Thunderbird → MailNews
Hardware: PC → All
Summary: bulleted list changes font, does not respect defaults for HTML messages → New paragraph clears formatting, does not respect prefs for HTML messages
Version: unspecified → Trunk
Use style sheets for mail composition: bug 245007.
See also bug 245581, bug 248129.
*** Bug 260784 has been marked as a duplicate of this bug. ***
Product: MailNews → Core
*** Bug 272752 has been marked as a duplicate of this bug. ***
Summary: New paragraph clears formatting, does not respect prefs for HTML messages → New paragraph clears formatting, does not respect font prefs for HTML messages
*** Bug 291481 has been marked as a duplicate of this bug. ***
*** Bug 292673 has been marked as a duplicate of this bug. ***
*** Bug 310908 has been marked as a duplicate of this bug. ***
Assignee: mscott → nobody
Summary: New paragraph clears formatting, does not respect font prefs for HTML messages → New paragraph (e.g. list) clears formatting, does not respect font prefs for HTML messages
*** Bug 315867 has been marked as a duplicate of this bug. ***
*** Bug 322857 has been marked as a duplicate of this bug. ***
This is a "me too".

I think this is a bug because I have specifically chosen Arial as my default font within Preferences->Composition->HTML Options. As such, I define that as meaning I want it to be Arial unless I say otherwise.

However, what happens is the compose window *starts* in Arial, but whenever some boundary-change occurs (like a bullet list), it falls back to "variable width". 

Shouldn't the default font be in that role? Why can't it fall back to Arial
 (for me)

I've just checked in Outlook, and no matter what boundary change I make (e.g. starting a bullet list), it kept its default font active.


Thanks!

As explain I did more or less the same experience. Compose a message, then edit the style by changing the format (body text -> paragraph) of a line, added the following line with [backspace] or [del]. It change Font, Size of the characters.
Evenif the HTML edit options have been set.
It appears that the Variable Width font chosen under Preferences.. Display.. Formatting.. Fonts.. Serif.. takes over.
The same is true when inserting a table. Variable width font is used for all the cells, instead of the user specified default font.
QA Contact: composition
Product: Core → MailNews Core
(In reply to comment #13)
> It appears that the Variable Width font chosen under Preferences.. Display..
> Formatting.. Fonts.. Serif.. takes over.

No, mine stays at "variable width".
Flags: wanted-thunderbird3?
Some thing related is the preference set in Options > Composition > HTML does not stay locked, rather it was seen to track the selection in the HTML Font dropdown. Since it migrates, there is no fallback to the Users preferred compose font. That leaves the fallback to the Display setting noted in Comment #13.

What seems to be needed is the Compose > HTML font selection being applied to the Body Tag as a base font. This would make the Font dropdown into an alternate font selector.  Additional justification for setting a base font within the body is the Insert HTML edit window prohibits editing the head and insertion of CSS rules in the head.

I also assert the Display font preferences not be applied to the Compose Window.
A person named "Arivald" suggested the following in news://news.mozilla.com:119/mozilla.dev.apps.thunderbird (Subject: "HTML Compose: Font selection lost when using Bulets etc")

> But there is solution: You may insert into body of message this HTML+CSS
> 
>    <style type="text/css">
>      body { font-family: Arial, sans-serif; }
>    <style> 

So Thunderbird could insert that code into the e-mails and change the variable for the font as the user selects it.

This sounds like a great solution that should be in Thunderbird.

The only thing I wonder about is: What happens to the fonts of the replied-to messages? Do they also get the font set by me, or do they keep the font set by the original sender? What about interleaved quoting?

Actually, I think that most messages have some font defined and Thunderbird's setting will not affect quoted text. Even if it does, I think it's more important that the current sender's font gets respected than the quoted text's font.
Since this bug is assigned to "nobody", I would like to point out that I consider this the most annoying and most important bug currently in Thunderbird, because it bites me on *every* e-mail I write (I use Thunderbird for corporate e-mails, and it's embarrassing and unprofessional-looking to have non-sans-serif or even mixed fonts e-mails go to managers and clients).
(In reply to comment #19)
> A person named "Arivald" suggested the following in
> news://news.mozilla.com:119/mozilla.dev.apps.thunderbird (Subject: "HTML
> Compose: Font selection lost when using Bulets etc")
> 
> > But there is solution: You may insert into body of message this HTML+CSS
> > 
> >    <style type="text/css">
> >      body { font-family: Arial, sans-serif; }
> >    <style> 
> 
> So Thunderbird could insert that code into the e-mails and change the variable
> for the font as the user selects it.
> 
> This sounds like a great solution that should be in Thunderbird.
> 
> The only thing I wonder about is: What happens to the fonts of the replied-to
> messages? Do they also get the font set by me, or do they keep the font set by
> the original sender? What about interleaved quoting?
> 
> Actually, I think that most messages have some font defined and Thunderbird's
> setting will not affect quoted text. Even if it does, I think it's more
> important that the current sender's font gets respected than the quoted text's
> font.

In my extension, i use rather simple way to allow quoted content have theit own styles.
While my extension process replies i check all <blockquote type="cite"> and if such <blockquote> contain embedded <style>, i do:
 1) Assign unique "id" attrib to <blockquote>
 2) update all style selectors strings,  to make them working only inside this  <blockquote>.

Here is some example 

Original CSS:

  <style type="text/css">
bofy {background-color: white;}
body,td,th {
	font-family: Verdana, Arial, Helvetica, sans-serif;
	font-size: 9px; color: #000000;
}
.style2 {color: #28768A}
a:link { color: #28768A;}
a:visited {color: #28768A;}
a:hover {color: #BA1D0C;}
a:active {color: #BA1D0C;}
.style13 {font-size: 8px}
  </style>

And in reply, after my extension complete processing):

<blockquote id="mid_49218293_6070400_XXX_XXX" cite="mid:49218293.6070400@XXX.XXX" type="cite">
  <style type="text/css">

#mid_49218293_6070400_XXX_XXX {background-color: white;}

#mid_49218293_6070400_XXX_XXX ,
#mid_49218293_6070400_XXX_XXX td,
#mid_49218293_6070400_XXX_XXX th { font-family: Verdana,Arial,Helvetica,sans-serif; font-size: 9px; color: rgb(0, 0, 0); }
#mid_49218293_6070400_XXX_XXX .style2 { color: rgb(40, 118, 138); }
#mid_49218293_6070400_XXX_XXX a:link { color: rgb(40, 118, 138); }
#mid_49218293_6070400_XXX_XXX a:visited { color: rgb(40, 118, 138); }
#mid_49218293_6070400_XXX_XXX a:hover { color: rgb(186, 29, 12); }
#mid_49218293_6070400_XXX_XXX a:active { color: rgb(186, 29, 12); }
#mid_49218293_6070400_XXX_XXX .style13 { font-size: 8px; }
  </style>


I use it about year, and it work with mails from TB, Outlook 2007, OE and GMAIL. I suppose this will work with all HTML mails.
Your extension sounds great. Can it be used (in modified form) to fix this bug?

If at all possible, please don't define font sizes in px (1 em is better!?). IMO, the recipient should always be the one to decide the size he reads his e-mails (Tools / Options Display / Font). (This is a pet peeve of mine - also for web pages).

And is it necessary to define link colors (visited, hover, active)?
Flags: wanted-seamonkey2?
Hi, everybody,
I'm also annoying with that bug, finally I do not use the HTML/CSS any more and I write in plain text. It match the "netiquette", it isn't "corporate" but I do the best I can and send main part of mails in joined files (not netiquette).
Nice to have, but not a priority.
Flags: wanted-seamonkey2? → wanted-seamonkey2-
It's incredible that energy is only put on "cool" features whereas bugs such as this one are not taken care of. Organizations and companies are relying every day on this kind of functionality and each time a couple of users stumble on these problems, Thunderbird do lose a lot of credibility.
(In reply to comment #24)
> Nice to have, but not a priority.

I tend to strongly disagree. Mail composition is the core of any mail client, and this is a very visible bug. I prefer not to send mails where the font type and size changes in the middle of the mail, and recipients are likely to be unimpressed. I have been using TB for years in a corporate environment and if I could choose between 100 new features and fixing this bug and would choose that latter.
I agree wholeheartedly. We also use thunderbird in a corporate environment, and a fix for this bug would definitely be a high priority for us.
Seriously...  

While many open-source developers would appear to prefer the world return to a time when plain text was king, for most users (corporate and personal) HTML mail is what's important.  In my mind this bug relegates Thunderbird to "toy" status only - while it's fine if you're sending messages that don't matter, anytime I want to ensure I don't look like an amateur I need to instead send my messages through a webmail client or - *gasp* - MS Outlook.

I understand that most developers with the inclination to work on this project likely fall into the "HTML Mail is Evil" camp - which explains why this bug has been open for nearly five years; since the developers aren't bitten by this bug, they don't feel the urge to scratch this particular itch - but sometimes you do need to cater to the needs of your users.  And this is one of those times.

I would imagine Thunderbird's "market share" has been dropping relative to even webmail services such as gmail.  Refusing to fix this bug will only further contribute to that downward slide.
Nicely put ;)

I also believe that desktop mail clients are more and more becoming a business-only tool as private users move to webmail and chat. And in a business environment HTML mail (as well as integrated calendar/task functionality and perhaps a collaborative mail server) are what matters.

Don't get me wrong, I do get it that TB is a free, open-source project with people mostly working on it in their free time, so I'm not really complaining (let alone demanding anything), just voicing my opinion ;)
> Seriously...  
> 
> While many open-source developers would appear to prefer the world return to a
> time when plain text was king, for most users (corporate and personal) HTML
> mail is what's important.  In my mind this bug relegates Thunderbird to "toy"
> status only - while it's fine if you're sending messages that don't matter,
> anytime I want to ensure I don't look like an amateur I need to instead send my
> messages through a webmail client or - *gasp* - MS Outlook.
> 
Yes. It is exacly why I develop extension to load HTML templates to every
email.
I need and use it in work, i communicate with clients using nicelly looking
mail, loaded from templates. If You want to give it a try, search AMO for
"Stationery". You may also contact me, I will help You to make nice looking and
compatible templates. 
Compatibility is issue, because user agents render HTML in many ways. And
Outlook 2007 do it in very disappointing way ...


> I understand that most developers with the inclination to work on this project
> likely fall into the "HTML Mail is Evil" camp - which explains why this bug has
> been open for nearly five years; since the developers aren't bitten by this
> bug, they don't feel the urge to scratch this particular itch - but sometimes
> you do need to cater to the needs of your users.  And this is one of those
> times.

Reason why TB composer is not fixed yet is much simpler: because it need to be
completly rewritten. It does not meet current standards in HTML formatting, it
do not understand CSS. For example it uses old, deprecated <font>! 

But before composer may be fixed, there is need to fix code used to serialize
(MIME encode) emails. It is also not CSS compilant.
for example, if You use "url(http://...)" in CSS, in <style> section, it will
convert it to 
  url(<a href="http://...">http://...</a>)
This "clever" conversion of course broke CSS.
Guys, please calm down, and let me explain what "wanted‑seamonkey2-" means and what it does not mean. (I'll do that here instead of replying to various mail I got on this subject.)

1. It does *not* mean that I'd think this should not be fixed
   (to the contrary, in fact).
2. It does *not* mean that we'd deny fixes - we love patches!
3. It's *not* about Thunderbird, it's a pure SeaMonkey flag. 
   (The code in question is largely shared, though, if either project fixes
   it the other will likely profit as well.)
4. There's a workaround (comment 17).
5. "wanted‑seamonkey2-" in association with "MailNews:Core" and "Status:New"
   and the points above means: this is a regular bug that should be fixed and,
   of course, we'd love to see patches for it, but we won't dedicate any focus
   or scarce SeaMonkey development "resources" to get it fixed in SeaMonkey 2. 
   Any help is really appreciated!

Some additional remarks:

> We also use thunderbird in a corporate environment, and a fix for this bug
> would definitely be a high priority for us.

Your patches are welcome. Try bribing your local geeks. ;-)

> for most users (corporate and personal) HTML mail is what's important.

I outright doubt and reject that. 

> Reason why TB composer is not fixed yet is much simpler: because it need to
> be completly rewritten. It does not meet current standards in HTML 
> formatting, it do not understand CSS.

True! :(
Mail editing depends upon the old Mozilla HTML composer code, which is quite outdated and virtually unowned. Even more so, since not even external derivations contributed back any of their fixes yet - although there are efforts to change this, this won't see fast progress, I'm afraid...
(In reply to comment #31)
> > for most users (corporate and personal) HTML mail is what's important.
>
> I outright doubt and reject that. 

Well, that seems to be the source of the lack of priority. 

Perhaps a more objective evaluation of the use of HTML vs plaintext would enable a more reasoned (as opposed to ideological) decision.

I work for one of the largest environmental engineering firms in the world (50,000 employees), and we, and all our corporate and government clients, all use HTML. All online stores I buy from send me HTML confirmations. All my friends (with only one exception) and family send me HTML e-mails. That's my little reality.
Karsten, thanks for taking the time to reply!

You wrote that comment 17 included a workaround, did you mean comment 19 perhaps?

Thanks again.

p.s.: would be interesting to somehow count in my inbox the number of HTML mails vs. plain text. Does anybody know how to do it? Could be an interesting input (if run by enough users) for the TB development team I guess, also in terms of prioritising this bug...
(In reply to comment #32)
> Perhaps a more objective evaluation of the use of HTML vs plaintext would
> enable a more reasoned (as opposed to ideological) decision.

Subjectively, my experience agrees with yours.  The only plaintext emails I receive are from people's Blackberries, a few (VERY few) of our automated tools (the vast majority of which were upgraded to send HTML mails years ago), and my two most-heavily open-source-oriented "geek" friends.

Karsten, I think most of the uproar over this bug is simply that people feel that support for HTML mail is not a priority for the Thunderbird (et al) development team(s).  Which you've pretty much confirmed.  I understand that there are technical issues preventing a rapid response to this bug, but truly feel that "you" (meaning "the devs", not necessarily you personally) are doing your userbase a disservice by NOT prioritizing HTML support.  Is there anything you can think of that we can do to try and change this, or would that be fighting a losing battle for us?

Arivald, I'll take a look at your extension and see how it works for me.  Would definitely be nice to have a workaround for myself, at least.
Worth taking a look at this recent post by the Lightning team: http://weblogs.mozillazine.org/calendar/2009/03/lightning_is_an_unusual_mozill.html

This seems to support my feeling that TB (especially when combined with Lightning) is primarily a business application, so development should aim to "please" business... Of course it is hard to judge without some proper research, but my feeling (and experience) is that 90% of business mails are HTML mails. They tend to come from Outlook, which I believe send HTML mail by default... Even if most business mails indeed do not include elaborate formatting, chances are that you will find a bold word here or there or a company logo in the signature...

Anyway, even a workaround would be great as a temporary solution, so if someone can come up with a description of the workaround for non-technical users, it would be highly appreciated!
Worth taking a look at this recent post by the Lightning team: http://weblogs.mozillazine.org/calendar/2009/03/lightning_is_an_unusual_mozill.html

This seems to support my feeling that TB (especially when combined with Lightning) is primarily a business application, so development should aim to "please" business... Of course it is hard to judge without some proper research, but my feeling (and experience) is that 90% of business mails are HTML mails. They tend to come from Outlook, which I believe send HTML mail by default... Even if most business mails indeed do not include elaborate formatting, chances are that you will find a bold word here or there or a company logo in the signature...

Anyway, even a workaround would be great as a temporary solution, so if someone can come up with a description of the workaround for non-technical users, it would be highly appreciated!
I found some useful information in Comment #13 that helped me to work around the problem I had. This was:

>It appears that the Variable Width font chosen under Preferences.. Display..
>Formatting.. Fonts.. Serif.. takes over.

Let's call that the 'Variable Width Font' - I found it in Tools... Options... Display... Formatting... Fonts...

I had chosen Verdana as my default font in Tools... Options... Composition... General... HTML... Font. (Let's call it 'Favourite Font' for now.)

When I start writing a new email it would default to the 'Favourite Font' - good. When I started writing bullet points, though it would change back to the 'Variable Width Font'.

The workaround for me was that I just had to change the 'Variable Width Font' (following the menu directions mentioned above.). The result was that even though the Name in the font dropdown box changes to 'Variable Width' the font in my email stays the same.

If you change the font using the dropdown in the composition window, you will still get the same problem when you use bullet points, however this made things bearable for me.

Karsten - Is this the workaround you had in mind or is there a better one?
hmmm... If I go to Tools/Options/Composition and choose "Verdana" as the font type, then close the Options window and open it again, the font type shown is again "Variable Width"... It seems the font type setting is not getting saved or is overwritten by some other settings...
Another observation: even though the font setting is apparently not saved/shown properly in the Tools/Options/Composition window (General tab), the setting is still saved as Verdana is shown as the font in the toolbar when I start writing a new message and this is the font type which is used when I start writing the message (until I start a bullet list, insert an image or a table, etc.)

However, in the Format/Font menu the selected font appears as Helvetica, Arial.

So at the same time TB shows three different font settings in 3 different "places":

- Variable width in Tools/Options/Composition;
- Verdana in the font toolbar;
- Helvetica, Arial in Format/Font.

So I'm wondering if it is issue with the Composer code or just TB not saving the font setting correctly?

I have found a bug which might be associated with this one: bug 426070 (https://bugzilla.mozilla.org/show_bug.cgi?id=426070)
(In reply to comment #42)
> >It appears that the Variable Width font chosen under Preferences.. Display..
> >Formatting.. Fonts.. Serif.. takes over.

That's particularly annoying if you want a *sans* serif font. Another (new) bug?

> When I start writing a new email it would default to the 'Favourite Font' -
> good. When I started writing bullet points, though it would change back to the
> 'Variable Width Font'.

Let's call it the "Display-Serif font". ;-) That's clearer, and it exposes the serif vs sans-serif bug.

We still need a response from Tb leadership about whether they also see HTML e-mail as a top priority. Until then Tb adoption will stagnate.

PS. Please see my newsgroup post(*) with the subject "Bug 250539 - open source's weakness" for related discussion.

(*) news://news.mozilla.com:119/mozilla.dev.apps.thunderbird
(In reply to comment #41)
> ... development should aim to "please" business... Of course it is hard to 
> judge without some proper research, but my feeling (and experience) is that 
> 90% of business mails are HTML mails. They tend to come from Outlook, which I
> believe send HTML mail by default... Even if most business mails indeed do 
> not include elaborate formatting, chances are that you will find a bold word 
> here or there or a company logo in the signature...

You are mirroring exactly my point of view. But in addition to your comment I estimate that 90% of private mails are HTML mails too. According to my experience many users find both the "Courier New" and the "Times New Roman" font ugly. So they want to create mails with a font that is more stylish. I often use bulleted lists or tables because I think they make a text look well-arranged and structured. The possibilty to emphasize some words by formatting them bold or italic is also very important for me.
(In reply to comment #45)
> We still need a response from Tb leadership about whether they also see HTML
> e-mail as a top priority. Until then Tb adoption will stagnate.

We have been writing on this subject for years (this bug was reported in 2004) without the TB team taking notice of it. I'm sure if they were aware of this problem they would resolve it. It is obviously a serious and annoying bug, isn't it? There may be too many bug reports. Somebody outside the core team should do kind of a triage. Important bugs would thus find their way more easily to the core team.
I reported this major defect long ago (probably under a different bug number).

I often send emails with legal content and regular use of bulleted and numbered text and certainly not in the font that automatically takes over.  I would have dumped TB long ago but for some features that are excellent.

What a condemnation of TB that I now regularly compose my text hassle-free in Word and paste it into a blank email!
I try not to be unhelpful or sarcastic but why does it take 5 years to fix a major pain in the butt most times I use TB.  

It may not be simple to correct but what time span is now envisaged to fix a basic bug that interferes with the simple task of writing an orderly message - ANOTHER 5 years?  Or ten?
I completely agree with you, Peter, I have no idea why this issue is not being corrected...
Well, I think the reason for nobody being working on it is: the status of this issue is still "NEW" and it is "assigned to nobody". Although it has been reported exactly 5 years ago...

What I don't understand is: why do the TB developers not notice this bug themselves? They seem either not to use TB as their favourite mail client or they don't care for aesthetics (either is hard to believe).

The other question is: what is Bugzilla good for taking into account that a ticket which is 5 years old and which has more than 50 comments and 15 votes obviously is not getting through to the developpers.
Which means we probably need more votes here, I just put mine, so we are up to 16, some of the guys on the mailing list haven't voted as there are currently 34 people, so would be great if you vote too, and maybe bring in more votes from others to make sure the bug get their attention...
To all those who are treating this Bug Reporting system as a discussion forum. It is not. Stop adding personal comments that are generating Bug Spam.
Confirming as still occurring in the latest Thunderbird nightly (Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.1.4pre) Gecko/20090906 Shredder/3.0b4pre).
A bug that is not fixed after 5 years and that is important for lot of people is way to say that Thunderbid will never become a mass market software. I use it because I like its features, but I don't thing ignorign a bug like this is a good signals for users.
I'm a developer and I work for a firm that have 6000 employees. With our clients we have a SLA of 45 days for bug correction. I know that Thunderbird is open source and the clients doesn't pay for assistance, but I think that for a software that want expand his use base, 5 years are too much. I will continue to use Thunderbird, because I use open source by more than 10 years and when I can choose, open source is and will be my choice, but I hope that a workaroud to this bug will be found before mozilla 2.0, that will not be here soon. I think 3 years or more as I see in the release plans. Then 8 years will be like a beam in the eye. I invite every one interested on this bug to VOTE.
We don't need votes, we need a patch.
We don't need lessons on business habits, we need a patch.
We don't need hypocritical comments, we need a patch.

Please, if you don't have anything to say which is directly related to writing a patch, DO NOT COMMENT. Bugzilla is NOT a discussion forum!
Agreed, but if the bug had been fixed as it should have been years ago there wouldn't be this frustration which is driving me nuts.
With respect, don't complain about the complaints - fix it!
I just wanted to point out, that this bug has still NOT been fixed in the latest release "Thunderbird 3 Beta 4".
In fact, it got worse. Now, navigating text with the END button in some cases (i assume at the end of a line) also breaks the text formatting and reverts newly typed letters to times new roman.
I can confirm this bug too!
I'm setting for example Arial as my default HTML font in Options>Composition, then click New Message button - so far so good.
BUT, if I have signature with different font (Comic Sans or whatever) and I move the cursor to the signature (just move it with the keyboard arrows or with mouse, no typing) area and then move it back - here it comes - "Variable Width" again...
Same valid if I create new message and do Ctrl+A then Delete (to clear the window off the signature) - "Variable Width"...
Can be reproduced at 100%.
Very annoying bug...
I can confirm this bug with v3 - 100% reproducible and has existed for many versions. I used to think it was on purpose (evil HTML!) but at this point it's embarrassing. 

I will add the following variant - HTML Compose Font (Verdana small for me) changes back to 'Variable Width' Medium when:
- Click into the body of a message you're replying to and then return to your email composition (sometimes - doesn't always happen)
Requesting blocking‑thunderbird3.1 because this 6 years old bug is the most important bug in Thunderbird.

Devs: PLEASE invest SOME of your time to get this bug fixed - at least slowly.
Flags: blocking-thunderbird3.1?
(In reply to comment #42)

This workaround is useless--I just tested this in TB 3.0, and the only thing modifying the "Variable width" font does is keep the font consistent within the composer--it does not change the actual font that gets sent! To reproduce, you can do this test:

Start composing an email, stop, then simply click the end of the line on which you are writing. This changes it to variable width, so type a few more words then send it to something like Gmail. The end result may look consistent in your composer window, but there actually isn't a font applied to the "Variable width" section. Here is an example:

http://img710.imageshack.us/img710/9018/tbbug.png

I switched back to Outlook for the interim... until a majorly annoying problem like this gets corrected I can't afford the extra time spent QA'ing my email for formatting problems. The open source community is great for competition, but I'm all too familiar with devs thinking of problems as features and not as bugs (I'm not a dev, but I'm a sales engineer :D).
I like so much about TB - all except editing a simple orderly message which is a pain.  Why have I needed to write many messages as a Word document and then paste it into TB for sending - for the last FOUR years?
Listen, guys, in order for a bug to get any real attention from the developers - you gotta make some noise! As you can see at the top of this page, the bug has only 36 votes and that is why its importance is only set to Normal! This is ridiculous! The developers will never pay any attention to a bug with Normal importance no matter how many posts you will have here, so my suggestion is that you start asking friends, forums fellow members, family, and anyone who can help to vote on the importance of this bug to increase its important to high...
My hope is fading, that anything will happen to remove this annoying bug. I even suspect that Bugzilla is not the appropriate place to report bugs (but what is the right place?). The facts are

- we have a severe bug
- this bug has been reported for the first time about 6 years ago
- there are numerous duplicate bug reports 
- the status of this bug report is "NEW" -> ridiculous
- this bug is assigned to NOBODY -> ridiculous

Guys, let's face it: what we are writing here is read by nobody, at least not by the Thunderbird programmers. There even seems to be nobody who is making a triage of the bug reports and forwarding the important ones to the core team. 

I have a dreadful suspicion: the Thunderbird programmers themselves do NOT use Thunderbird. Otherwise they would have noticed this bug...
So I thought I'd check how the Bugzilla system works. So I went to BugZilla and did a search for all Thunderbird Bugs containing the word Thunderbird (you cannot view all bugs - weird).

Go here and sort by "SEV" - 200 Bugs on the first page and only six (6) have been assigned. Zero of the "critical" bugs have been acknowledged (user designated "critical").
https://bugzilla.mozilla.org/buglist.cgi?query_format=specific&order=relevance+desc&bug_status=__open__&product=Thunderbird&content=thunderbird

So yeah it would appear there's a whole lotta bugs and no one paying any attention to them due to sheer volume. So how does one try to help the team discover what in my (our) minds is a serious bug that would impact broader adoption of the client or professional use?
votes, my friend, votes. Critical does not mean it has votes, it only means that this is how it was marked by the OP.
You can use Advanced Search to find Thunderbird bugs, but the interesting thing is that this bug is listed as Product: MailNews Core, not Product: Thunderbird. I kept wondering why this bug didn't show up in the results. The output can be sorted by Votes.

By the way, this bug has 38 votes and 48 people on the email list.
The simple reason this is a "MailNews Core" bug is it is common shared code with SeaMonkey.

The root of this bug is in Composer, a code module without a maintainer. The software engineer who wrote the code was a Netscape employee that AOL layed off 8 years ago. No one has come forward to develop a new replacement, so we are stuck with what we have.
As far as I know there have been some further developments to the Composer code: NVU (http://www.nvu.com/, discontinued) and then its "unofficial" bug-fix, KompoZer (http://www.kompozer.net/). Maybe this bug has already been fixed in either NVU or KompoZer? Maybe someone from the KompoZer team (the project seems to be "alive" would be willing to work on this bug? I'll post this question on the KompoZer forum...
(In reply to comment #74)
> My hope is fading, that anything will happen to remove this annoying bug. I
> even suspect that Bugzilla is not the appropriate place to report bugs (but
> what is the right place?). 

I too wonder whether Bugzilla is the right place to voice what is essentially a user concern. That is to say this is a problem encountered by people that actually USE TB and not sysadmins etc who are more inclined to report bugs on setup and integration (e.g. Exchange servers, LDAP, etc.)

Mozilla have recently (since the release of TB3.0) been calling for help in answering user queries via their Get Satisfaction forum. 
http://getsatisfaction.com/mozilla_messaging

Since this is a much more end-user focussed environment as opposed to a developer environment, it might be worth us all going there to make some noise. Maybe someone is listening. After 6 years I think we can all safely say that in Bugzilla, no one can hear you scream...

PS: while you're on Get Satisfaction, have a look and see if you might be able to help out a fellow TB user with some of their queries. Give and ye shall receive.

http://getsatisfaction.com/mozilla_messaging
GetSatisfaction is a great place for people to click on the "I have this problem too".  But please don't try to "make noise" -- noise just makes it harder to talk, and get anything done.  In particular, complaining about how uncaring others seem to you to be doesn't really get them on your side.

For the record:

a) we know about this bug, and we know it affects a lot of people.
b) we don't currently know how to fix it.
c) I've tried to find someone who can fix it.

Vote if you want, but the more there are "me too" comments on this bug, the _harder_ it will make it for the developer who tries to fix this bug to actually understand the details of how to fix it.
I kind of disagree with David.

 - This is an ongoing legacy bug that has seen no improvement in major releases.
 - Anyone needing a mail client for business will drop TB if they can't even format a message properly.
 - The developer that tackles it will be able to reproduce it.  There are already several bugs submitted on this topic. (showing how many people it bothers, who take the time to want to improve the product)

If we fail to show the number of people this is bothering, then it will take second fiddle, as it obviously has done for years....
(In reply to comment #82)
> a) we know about this bug, and we know it affects a lot of people.
> b) we don't currently know how to fix it.
> c) I've tried to find someone who can fix it.

Thanks David. Had we known these three facts before, we would not have complained the way we did. If you know about this bug please change the status from NEW to whatever-you-want and leave some remarks. It is very frustrating for users who report bugs and find their report unanswered after 6 years. Just "talk" to us and we will be more understanding.
What TB currently does is adding style instructions to the body itself. There are no instructions neither for <ul> nor for <ol> nor for <td>. 

My suggestion how TB should handle HTML formatting: put a <style> section as follows (exemple, may not be complete) to the HTML header:

<html>
  <head>
    <style>
      body,td,ul,ol {font-family: verdana, sans-serif; font-size: 10px;}
      p, ul, li {margin-top: 10px; margin-bottom: 0;}
      blockquote {margin-left: 5px;}
    </style>
  </head>
  <body>
    ...
  </body>

No style instructions in the <body> section, unless the user changes font style for some parts of the text.
NEW is the correct status for a bug at this stage.
Keywords: helpwanted
Whiteboard: [see comment #82]
David, thanks for your long awaited response, please read the following comments to your comment:

"In particular, complaining about how
uncaring others seem to you to be doesn't really get them on your side."
- I think we are all on the same side here, the end-users best interest and of course the developers interest is to iron out as many bugs as possible, there is no such thing as your side and our side.

"For the record:
a) we know about this bug, and we know it affects a lot of people."
It affects all users, and as "wolf_thunder" accurately wrote -  Anyone needing a mail client for business will drop TB if they can't even format a message properly.

"c) I've tried to find someone who can fix it."
Any success/progress? Are you still looking?

"Vote if you want, but the more there are "me too" comments on this bug, the
_harder_ it will make it for the developer who tries to fix this bug to
actually understand the details of how to fix it."
This statement completely doesn't make any sense to me. The bug reproduction is so easy for any developer and most of the comments here are related to how to make the people @Mozilla actually pay attention to the issue.
The details of how to fix it will not be in the comments either, only the details of how to reproduce it.
By the way, I am not sure if everyone here know:
The honorable Dr. David Ascher is the CEO of Mozilla Messaging.
I appreciate your participation in this thread and am looking forward for your response, as I am sure all others do too. :-)
I appreciate the frustration, let me see if I can give a bit of context, given that this bug is already too long.

From a developer's point of view, a bug is kind of like a shared puzzle marked "TODO".  The puzzle part is because fixing bugs is hard, often much, much harder than it would seem to a non-developer.  The shared part is the collaboration bit of a public bug tracker -- developers can help each other out in solving these hard problems, by sharing their experience of the codebase and the like.  The TODO part is the pressure to fix something.

Now, there are lots of factors that influence whether a given developer can successfully take on a bug.  Off the top of my head, I can come up with:

 - what part of the code is affected?  Some parts of the Thunderbird codebase are as scary as the caves in Indiana Jones, full of snakes and booby-traps.  Only heroes and fools go there. 

 - how confident is the developer that he/she can fix the problem without causing more problems?  In newer parts of our codebase, we build automated tests, to minimize the risk of 'collateral damage'.  That wasn't true when the older code was written.

Fixing particular bug scores exceedingly low on the above two metrics: no one involved in developing Thunderbird, whether paid or volunteer, understands the code in question; it's scary (sharp sticks jutting out of the walls!); there is no test coverage at all.

At this point, most devs will walk away from that kind of bug, except if it's a problem they themselves encounter a lot, and that is annoying them personally.  It's true that for a variety of reasons, developers tend to prefer plain-text emails -- as a result I suspect most developers don't encounter this bug.  

Now, a bug in a public bug tracking system where anyone can comment has one more attribute: while you're sitting around with a colleague trying to solve a really challenging problem, you're surrounded by a crowd of people who really want that problem fixed.  The crowds tend to be more or less friendly (this bug isn't horrible by those standards, but not great).  The more noise the crowd makes, the harder it is to actually fix it.  To take a silly analogy, knowing that the fate of a city depends on your ability to defuse the bomb does not make defusing the bomb easier.

The short bit: you're currently virtually standing around a puzzle, and yelling that someone should solve the problem -- it's not a particularly enticing area for a would-be puzzle solver.

So, to recap:

1) yes, this is a bug.  It's an annoying bug for sure.  There are however lots of other issues that offer a better mix of criticality + safety-to-fix + ability-to-fix than this one.  I'm hopeful it will get fixed eventually though (see c)

2) if you want to help get a bug fixed and contribute to this public benefit project, here are a few generic DOs and DON'Ts:

   - DO try to create the most precise, accurate, unambiguous steps to reproduce the bug

   - DO promptly respond to requests for specific information from QA triage folks or developers

   - DON'T add noise by commenting on a bug saying that you have it to, or complain about how long it's been since it was fixed.  Instead, add yourself to the cc list, or vote for the bug -- we do look at those numbers.  In "advocacy" bugs, the technical information developers need is often buried among lots of other comments.

   - DON'T express anger or frustration towards the people who are trying to help (or to anyone, really).  It may make you feel good for a second, but it won't help.

I know that's not really feeling like you can do much to help.  So here's another suggestion: Thunderbird developers are a community of sorts.  We often do things for each other.  In particular, if there's someone we know has been very helpful in areas like testing, bug triage, or verifying bug fixes, or other areas like that, we naturally want to help them out when we can.  Those kinds of informal ties do help get bugs get the right attention.  

So if you want to contribute to the project, look around, there are lots of ways for non-developers to get involved. In particular, we would _love_ to have people help answer questions from users on the http://getsatisfaction.com/mozilla_messaging/ support site.  It's easy, and it feels great to help someone out.

3) This bug has some relatives in the general arena of HTML composition.  I too would like to see the most egregious such bugs fixed, and as a result am looking to contract someone who can help fix this and other related bugs in editor.  I don't think it makes sense to keep a bug report updated with my progress on these kinds of issues.  When we have someone, patches will show up, then reviews, then hopefully checkins.

Back to regularly scheduled work.
This is a rather complex issue to solve, because that's the current behaviour of nsEditor::SplitNodeDeep() to not really split a node and just move the caret's position past the node's end if the right-end part after caret is collapsed.
You'll notice how it goes if, instead of making a list right after hitting the CR key, you type an extra char before.

Let me think a bit about it please.
Daniel - please think about it! and keep in mind it's not just lists, try for example leaving and returning to the exact same spot in a sentence - by adding a recipient to the TO: field mid sentence, viola the font has changed.
Oy vey, this does sound complex, Daniel, but there aren't many people more suitable than you to fix this never-ending-bug. Great to see you here too! :-)
(In reply to comment #91)
> Daniel - please think about it! and keep in mind it's not just lists, try for
> example leaving and returning to the exact same spot in a sentence - by adding
> a recipient to the TO: field mid sentence, viola the font has changed.

That one is a _totally_ different issue: before moving the focus to the To: field, the caret is inside the innermost <font> element. When you click back in the editor leaving the To: field, you place the caret outside of the outermost <font> element, hence the font change. It's purely a selection problem while the scope of the current bug is more in the HTML editing rules.
CKEditor: http://ckeditor.com/demo

is a very capable HTML editor released user GPL, LGPL, and *MPL* licenses: http://ckeditor.com/license

Why not use that as the foundation for an improved Composer, cutting out whatever functionality is not needed?
Mmm.  I guess is Mozilla went that route, they would have to pony up for the OEM license: $1450 USD; however, what are the comparable costs of hiring someone to untangle Composer vs CKEditor license + man-hours to modify and integrate it.
Sorry for the spam:  I didn't read carefully enough.  Since Thunderbird is open source, it would not require the OEM license and could use the CKEditor code free of charge.
FYI, I would be very interested in leveraging existing projects like CKEditor for a new editor UX.   That's a longer term project, which should be done in parallel with fixing bugs in the current code.  (I just filed bug 539299 to discuss that idea, so we don't clutter this bug even further).
(In reply to comment #97)
> FYI, I would be very interested in leveraging existing projects like CKEditor
> for a new editor UX.   That's a longer term project, which should be done in
> parallel with fixing bugs in the current code.  (I just filed bug 539299 to
> discuss that idea, so we don't clutter this bug even further).

for TB, why not. But Gecko still needs the editor to be fixed for contenteditable purposes anyway...
(In reply to comment #93)
> (In reply to comment #91)
> > Daniel - please think about it! and keep in mind it's not just lists, try for
> > example leaving and returning to the exact same spot in a sentence - by adding
> > a recipient to the TO: field mid sentence, viola the font has changed.
> 
> That one is a _totally_ different issue: before moving the focus to the To:
> field, the caret is inside the innermost <font> element. When you click back in
> the editor leaving the To: field, you place the caret outside of the outermost
> <font> element, hence the font change. It's purely a selection problem while
> the scope of the current bug is more in the HTML editing rules.

To an end user it's the same - composer isn't behaving as expected. I opened a second bug, it was resolved as a duplicate of this bug. 

https://bugzilla.mozilla.org/show_bug.cgi?id=537538
(In reply to comment #99)

> To an end user it's the same - composer isn't behaving as expected.

This is not exactly an end-user place after 99 comments. Please don't bloat bugs. The current one is about turning a collapsed selection with a non-null TypeInState into a list, period.
(In reply to comment #100)
> The current one is about turning a collapsed selection with a non-null
> TypeInState into a list, period.

I filed a bug about the font switching to variable width when moving to the end of a sentence and it was filed as a duplicate and merged here.  My bug had nothing to do with list composition. Why was it merged here if this is "list" only? 

So let's re-open NEW bugs that point to all the html composition erronious behaviors if we want to eliminate all the bugs that have been filed and that will get ignored with the "The current one is about turning a collapsed selection with a non-null TypeInState into a list, period." attitude.


If I spell check an email tha has been exchanged multiple times with an Outlook user, the TB spellchecker checks embedded style mark up language, not just the visible text.  New bug?


Also, in an exchange that has bone back and forth multiple times with said Outlook user, the subject and body lines are merged as one long line in the previous threads that are indented deeper in the dialog.

As such:

On 12/23/09 at 12:45 PM, Sender wrote:
      Re: Review this documentWolf, this is great stuff.  Let me know....

The "Wolf, " part should be on a new line....

New bug?  Or HTML composition bug?

After seeing the treatment this bug has gotten for the past 6 years (nothing), and the merging of bugs due to "duplicate" (which is then deemed different) - I am not about to waste time filing new bug reports for each issue.
(In reply to comment #100)
> The current one is about turning a collapsed selection with a non-null
> TypeInState into a list, period.

I, and I suspect most here, would prefer if this bug was about what it says in the Subject line, namely: "New paragraph (e.g. list) clears formatting, does not respect font prefs for HTML messages".

If your formulation ("turning a collapsed selection with a non-null TypeInState into a list") covers that in a significant was (say >75%), then great. If it only covers a subset (say <50%), then I would request you create a new bug and make this one "depend" on it. That would be more fair to those who are following this bug in the hope of a more comprehensive fix.

PS. Welcome back Daniel. You are a true legend in the mozillaverse.
I have a tentative patch for the list issue. Ironing it.
Daniel, thank you so much for the effort. Having you and David paying attention to this bug has made my day ;)

(sorry for using Bugzilla as a discussion forum... again).
This is a fix proposal for the list issue. Please test it and let me know if this is the desired behaviour. Warning: *must* be tested in both Seamonkey Composer and Thunderbird.
Sorry for the ignorance, Daniel, but how do I install this patch into my TB 2? All I see is just the patch code, no file to download and even if I just copy and paste it into a file, how do I install it?

TIA
(In reply to comment #106)
> Sorry for the ignorance, Daniel, but how do I install this patch into my TB 2?
> All I see is just the patch code, no file to download and even if I just copy
> and paste it into a file, how do I install it?
> 
> TIA

David Ascher, can you forward the patch to your team for testing purposes please? A report here or by private email welcome. Thanks !
(In reply to comment #106)
> Sorry for the ignorance, Daniel, but how do I install this patch into my TB 2?
> All I see is just the patch code, no file to download and even if I just copy
> and paste it into a file, how do I install it?
> 

The patch has to be applied to the proper source code and a new build compiled for testing. Mozilla Messaging has test rigs for this without the modified code being added to the trunk builds. If it works, it should find it's way into the Tb3 trunk.
The next step would be to make tryserver builds. Daniel, if you want be able to do that, steps are at https://wiki.mozilla.org/Thunderbird/Infrastructure/TryServer 

In the meantime, I'll see if I can get someone who already has a cert to spin up a build.  I don't have time today.
Hmm, philor reminded me that this is a mozilla-central patch, and currently our tryservers only take patches against comm-central, so the "simple" way to get a test build up won't work.  I'm not sure how hard that is to change, but I suspect it's not trivial.

Furthermore, in parallel with testing, this is a gecko patch, so even with review landing it will require:

 - automated test coverage
 - landing on trunk, baking, and backporting to whatever branches we care about.

Daniel, are you up for doing step 1 which would be the test? (I presume it'd be a mozmill test, but I don't know for a fact.  I don't know what the state of /editor tests is).
(In reply to comment #110)
> Daniel, are you up for doing step 1 which would be the test? (I presume it'd be
> a mozmill test, but I don't know for a fact.  I don't know what the state of
> /editor tests is).

mozilla-central doesn't run mozmill tests. You could probably do a mochitest, there are already some present in that location:

http://mxr.mozilla.org/comm-central/source/mozilla/editor/libeditor/html/tests/
Great news to see this is being tackled at last.  The following test will show a current problem that shouldn't happen when the problem is fixed.
1  Make a numbered list in Word.  Paragraphs 1, 2, and 3 only, two words on each line in Arial

2  Start a new message in TB.  Write a few words in one line in Comic Sans MS  

3  Cut and paste the 3 lines from word into TB under the first line – it shows the 3-line list as Arial – OK

4  In TB select all – the font shows mixed – OK

5 Change font from Mixed to Comic Sans MS – not OK.  The font is stated to be Comic MS  but the first two numbered lines stay in Arial.  Highly the two Arial lines and the font wrongly shows as Comic Sans.  You cannot change the actual Arial font of these two lines to ANY font they are frozen as Arial
Not knowing that daniel already proposed a patch, I came up with something else. It's not finished at all, but it a different approach. The first tests are promising. Changing fonts from the toolbar doesn't work yet, it needs the same change. Also, font-size etc doesn't work yet.
The idea is that all new paragraphs etc will be surrounded by a font node with a font-face set.
But before I go further, i'd like some feedback. Daniel, what do you think of this approach?

(disclaimer: I'm far from an editor expert. I just looked at the idl files)
Comment on attachment 422007 [details] [diff] [review]
different approach

(In reply to comment #113)

> The idea is that all new paragraphs etc will be surrounded by a font node with
> a font-face set.
> But before I go further, i'd like some feedback. Daniel, what do you think of
> this approach?

Surrounded ? Wow. A font element cannot contain a paragrah or a block-level
element. Please, do NOT do that. Sorry, but I am r-'ing it.
Attachment #422007 - Flags: review-
Comment on attachment 422007 [details] [diff] [review]
different approach

Ok, my wording wasn't very accurate. I meant that the text of the paragraph is surrounded. No real <p> nodes are used. Just as without the patch.
Example output:
  <body text="#000000" bgcolor="#ffffff">
    <font face="Baskerville">text<br>
      text<br>
    </font>
    <ol>
      <li><font face="Baskerville">more text</font></li>
    </ol>
    <font face="Baskerville">some more<br>
      end<br>
      <br>
    </font>
  </body>
Attachment #422007 - Flags: review-
Comment on attachment 422007 [details] [diff] [review]
different approach

(In reply to comment #115)
> (From update of attachment 422007 [details] [diff] [review])
> Ok, my wording wasn't very accurate. I meant that the text of the paragraph is
> surrounded. No real <p> nodes are used. Just as without the patch.
> Example output:
>   <body text="#000000" bgcolor="#ffffff">
>     <font face="Baskerville">text<br>
>       text<br>
>     </font>
>     <ol>
>       <li><font face="Baskerville">more text</font></li>
>     </ol>
>     <font face="Baskerville">some more<br>
>       end<br>
>       <br>
>     </font>
>   </body>

Ah, ok, that's a better. But please also understand that copying the face attribute is not enough. You also need the size one. You also need the style attribute in case you copy html text from outside of TB. You possibly need class if you're adding text to a quoted text or if TB ever extends the richness of HTML-based email... Let's say your idea is a workaround, strictly limited to TB and that does not affect other editor-based applications. I have the gut feeling this is not the right approach since this problem is really in the core of the editor, not in the apps above.
I'm cancelling my r- then and since I'm no mailnews peer, I leave the decision to davida. But I don't think I would follow that path myself.
Comment on attachment 422007 [details] [diff] [review]
different approach

I'm no peer either, off to dmose.
Attachment #422007 - Flags: review?(david.ascher) → review?(dmose)
(In reply to comment #116)
> I have the gut
> feeling this is not the right approach since this problem is really in the core
> of the editor, not in the apps above.

I just looked at how TB read the pref "msgcompose.font_face", and noticed that is just seems to insert a <font face=""> element. If you insert a list, it is added outside the font element. It should add a new font element to set the font face for inside the list. Same when you close the list.
I think that the API to do that exists, it is nsIHTMLEditor.addDefaultProperty(). So the problem is, in my opinion, in the calling applications. They just use the wrong API.
But then again, I don't really know much about editor.
And yes, the patch is very much incomplete. I know that. I just don't think that working on it makes sense until we agree it the approach is the right one.

(btw, I think that using <span> and css would be really the right way, but I don't see how to do that...)
(In reply to comment #118)

> But then again, I don't really know much about editor.
> And yes, the patch is very much incomplete. I know that. I just don't think
> that working on it makes sense until we agree it the approach is the right one.

I am an editor peer and that's why I can say this is an editor core bug. Nvu and BlueGriffon have the same issue and I have to solve it for BlueGriffon anyway.

> (btw, I think that using <span> and css would be really the right way, but I
> don't see how to do that...)

Using css in email messages raises other issues: some email clients choke on that. Interoperability of composed "rich-text" messages among UAs is a major item that often transcend "purity" wishes, unfortunately...
Daniel, I was wondering if this excel-to-TB bug https://bugzilla.mozilla.org/show_bug.cgi?id=250539 got anything to do with the bug discussed here and can be resolved at the same time. It is also a bug that affects every single TB version since the first and does not affect any other mail client.
(In reply to comment #119)
> I am an editor peer and that's why I can say this is an editor core bug. Nvu
> and BlueGriffon have the same issue and I have to solve it for BlueGriffon
> anyway.

Can it be that writing a mail has different requirements then writing a web page? For example, when I reply to a mail, and add my text between the quoted text, I want it to use the font that I choose in the preferences. But when I write a document, and insert a paragraph somewhere, I want it to use the font of the surrounding text.
Are the requirements written down somewhere?
Is my stylesheet approach as I mentionned in post 2010-01-12 08:55:41 PST out of focus? By the way: that's what GMX does.
One more aspect:
It is very common, especially in Microsoft products like MS Outlook and MS Word, that the shortcut [Ctrl-SpaceBar] clears all formatting and sets it to "Default". 

In fact, if you mark text and press [Ctrl-SpaceBar] in Thunderbird, all "bold", "underline" and "italic" formattings are removed. But the font changes to "Variable width" too. My expectation is, that the font within the marked section will be reset to the default font which the user has defined in the preferences dialogue.
(In reply to comment #121)
> when I reply to a mail, and add my text between the quoted text, I want it to 
> use the font that I choose in the preferences. But when I write a document, and 
> insert a paragraph somewhere, I want it to use the font of the surrounding text.
I do not agree. In any case, I want that the text I type uses the surrounding font. This is the familiar behaviour of any text processing program and HTML editor I know. 

If you speak about inserting text from the clipboard, there are two ways of doing this. Either you use [Ctrl-v] resp. "Edit > Paste" or you insert it by "Edit > Paste Special". In Thunderbird you can use the shortcut "Shift-Ctrl-v]. In the former case, you paste formatted text. In the latter case, you paste plain text (unformatted).
The issue is getting even worse now. Maybe with TB 3.0.1 (?). For a couple of days I'm encountering what follows: 

-> Create a new mail 
-> Place the cursor into the editor area either by using the [Tab] key or by clicking: 
   the font style dropdown shows the font according to your settings, OK so far
-> Begin typing (just one keystroke is enough):
   the font style dropdown immediately changes to "Variable width". With TB 2.x and 3.0 the font style only changed when you used bulleted or numbered lists, tables and so on. 

Additionally and maybe in correlation with this:

-> Open a mail that you have received
-> Reply using [Ctrl-r] shortcut or by clicking the [Reply] Button 
-> the Cursor is now placed within the area that cites the sender's text and which is marked by a vertical line
I hereby withdraw Comment 126. It is very strange. As soon as I had reported this comment and had restarted TB, the "even worse" issue was not reproduceable any more. Sorry for bothering you unnecessarily.
Wearing 3.1 driving hat: 3.1 is mostly about stuff that will prevent folks from updating from Tb2 -> Tb3, and this doesn't feel like one of those things, so blocking-3.1-, but wanted-thunderbird+ since we should very much do better here.

Wearing reviewer hat: I hope to get back to this bug sort through all the technical details before too long, but a lot of the other stuff in my queue feels even higher priority.  :-(  So if you can find another peer who is interested in taking a shot at it, feel free to move the review!  I've added philor to the CC in case this is the sort of thing he'd find entertaining...
blocking-thunderbird3.1: --- → -
Flags: blocking-thunderbird3.1? → wanted-thunderbird+
> 3.1 is mostly about stuff that will prevent folks from updating 
> from Tb2 -> Tb3 ....

Ya, it was broken in tb2, and still is broken (although worse now), so why fix it just yet.... who really needs html email composition anyway? 

An email client that can't compose a proper email message.  But that is not really one of those vital things to an email client, is it?
I am also quite confused with your statement, Dan. As WOLF_THUNDER wrote - HTML composition is extremely important in today's clients.
Developers above already suggested ways to fix it, why not just proceed with these and have this fixed at last?
Please vote for this bug. So someone will put attention on it. Hope so.
While I understand dmose's comment about the purpose of the 3.1 release and how this bug is not blocking that release, I'm genuinely worried that this will put off fixing this bug by another 5 years. Finally there is a proposed fix (by  Daniel Glazman), and it seems it would not even be tested. Very sad indeed. I've heard many times that this bug was extremely difficult to fix because it was a fault in the composer module etc etc, yet Mr. Glazman needed just a few hours to address (at least part of) the problem. I've been using TB since version 0.9 and I'm growing more and more amazed that such a major fault in such a crucial feature is left untouched release after release.
I personally think this is a VERY important bug.  If I use a custom font setting then it bites me EVERY DAY, and several times a day.
I try to post a comment on David Ascher blog http://ascher.ca/blog/2010/02/10/thunderbird-in-2010/, asking for fixing this bug, but my comment is awaiting moderation. If someone else want to post may be our voices will be heard.
This bug is wider than has been described.

It appears in TB3.0.3
No account of the default font settings in the composition settings.
Moreover when you reply to an email (I default my cursor location to be ABOVE the quoted text), the cursor is initially located at the start of the quoted text (ie. IN the quote) and upon pressing return it becomes partially hidden under the top address border.

Very tedious as I then have to highlight the text and change the font.
If you then carry on typing it goes back to whatever font it feels like ("variable" in my case).
So I find myself typing a complete note and then carefully adjusting the typeface.

It appears to take account of the colour that is chosen in the composition settings, just not the typeface.
I've been brave and installed 3.1 Beta. The problem is resolved there. :-)
KevB - I installed 'Lanikai' 3.1b1 (Windows) - disappointed to see that none of the issues have been fixed. 

User defined HTML Small Font changes back to ThunderBird default of Variable Width Medium in all cases discussed here: Bullets, clicking out of the editor window and back, adding text into the body of a reply etc.

http://i.imgur.com/2iJ7z.jpg

The bug is also not listed for this release:
https://bugzilla.mozilla.org/buglist.cgi?query_format=advanced;resolution=FIXED;target_milestone=Thunderbird%203.1b1

http://www.rumblingedge.com/2010/03/08/thunderbird-3-1-beta-1-released/
I must confirm "Comment 138". The bug still exists, in fact it even has become worse. The "Paragraph style" and the "Font style" dropdown menus are now inaccessible as well as the "Insert" and the "Format" pulldown menus. 

I can't imagine why this bug should be so difficult to fix. Let the settings create a stylesheet and put this stylesheet to the mailheader.
(In reply to comment #139)
> The "Paragraph style" and the "Font style" dropdown menus are now
> inaccessible as well as the "Insert" and the "Format" pulldown menus. 

I think that is another (regression) bug in the "recent" (i.e., 2-6 weeks) nightly builds. Bug# anyone?

Workaround: Click in the "To:" line and then back into the text body.

> Let the settings create a stylesheet [...] to the mailheader.

That would be a great *interim* solution. However, Thunderbird should not be reformatting the quoted portion of the text (because it would destroy the original author's (perhaps meaningful or personal expressive) styling.

I think at this point, I would be happy with almost *any* (interim) solution.
in TB 3.1 beta 1 the bug definitely still exist, maybe it's even worse then in 3.0.4, cause the buttons to trim the font and -sizes before sending are greyed out the most time ?!

In TB 3.0.4 i tried this add-on to solve or improve my problems:
http://nic-nac-project.org/~kaosmos/realborders-en.html

with a little success by setting the fonts, but only in font-type at varible width, bullet lists etc., unfortunately not in the size!

So it's only a half-solution, but what is the question: if a add-on programer is able to to build such a addon, i think it should not be impossible for mozilla to fix this fu***ng bug for us!
Joerg, I understand that you're (quite reasonably) frustrated that this bug hasn't been fixed yet.   However, comments like #141 make Bugzilla an unpleasant place for people to try and do the work you'd like to see done.  Please review <https://bugzilla.mozilla.org/page.cgi?id=etiquette.html> to see what sorts of comments are and are not appropriate for Bugzilla.
Attachment #422007 - Flags: review?(dmose) → review?(philringnalda)
Comment on attachment 422007 [details] [diff] [review]
different approach

Handing review off to philor.  Note that this patch wants to have an automated test (presumably using mozmill) in order to land.
Hi everyone,
I found a solution for this problem. I have installed Stationery extension :
https://addons.mozilla.org/en/thunderbird/addon/4394
I have created a default HTML template for it. In the template, I have put in the body a div element. The div element contains my font preferences, for exemple:
<div  bgcolor="#ffffff" text="#333333" style="font-family: Helvetica, Arial, sans-serif; font-size:small;">

Automatically, I compose my mail inside this div element.

It is working great for me, it does not modify the replied message, and keep my font as I defined in the HTML ! You can check the HTML generated in the HTML editing tabulation menu (added by Stationary).
Hmmmm, this extension seems to work fine. Great, I'm suprised... Strange, - why have the Thunderbird developpers not found a solution for years if the solution exists? Thank you for this hint.

There is a tiny flaw though. The "font-style" dropdown indicates "Variable width" and this made me worry the first 2 or 3 times I composed a new message. But I verfied the result: the recipient gets the mail with the correct style and with the correct size. 

Conclusion:
This extension is a great workaround. But the bug should be fixed all the same. It is irritating if the preferences you set via Tools > Options do not take any effect because an extension is predominant. It is also irritating if the "font-style" dropdown does not indicate the font-style the mail is actually being written. But again: a very good workaround.
Here is my template used for Stationary extension :

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html><head>
</head>
<body>
<div style="font-family: Helvetica, Arial, sans-serif; color:#333333; font-size:small;">
Hi,<br/>
<br/>
Regards,<br/>Vincent CARON
</div>
</body></html>
Yes granted, but: where do you put the html-code from post 145?
I use the addon "Quicktext" for adding different (also html-formatted) signatures, so maybe do i have to put the string 

<div  bgcolor="#ffffff" text="#333333" style="font-family: Helvetica, Arial,
sans-serif; font-size:small;">

in every pre-defined signature? And: am i able to change font-size (or make some words bold for example) inside the div?
(In reply to comment #148)
> in every pre-defined signature? And: am i able to change font-size (or make
> some words bold for example) inside the div?

Yes, You can.

TB composer change fonts and colors using old, obsolete <font> tags. Also default HTML font is implemented as pre-inserted <font> tag. it is why it fail on lists, tables, etc.

But here is not good place to discuss Stationery extension issues. 
If You want more help with building Your template for Stationery, e-mail me.
Joerg - When you install the Stationery Add-on this allows you at apply predefined formatting to the BODY of an email (i.e not the signature). You save your custom format as an HTML file somewhere on your machine (e.g. /home/username/my_default_email_style.html)

Then you set this as the default stationery for the add-on to use. Go to Tools>Add-ons> Stationery >Preferences and 'Add New'

One issue that I've found with this solution is that by creating an empty div such as:

<div  bgcolor="#ffffff" text="#333333" style="font-family: Helvetica, Arial,
sans-serif; font-size:small;">
</div>

This make it hard to ensure that you're actually typing WITHIN the div and not before it or after it.

caron's suggested example where they have included some text within the Stationery html file then allows you to know exactly where you are typing. For example:

<div  bgcolor="#ffffff" text="#333333" style="font-family: Helvetica, Arial,
sans-serif; font-size:small;">
Hi,

START TYPING HERE

Kind Regards,
figgs
</div>

This means you can be sure that you will start typing within the div, therefore getting the benefit of the correct formatting and not typing before or after it.

It also means that any signatures are added wherever they are normally added and are not altered by this formatting.

I agree that this is a workaround and not a fix - but I'm willing to give it a go and see if it infuriates me slightly less than the existing TB functionality
(In reply to comment #146)
> Hmmmm, this extension seems to work fine. Great, I'm suprised... 

I write this extension purely to help myself with my business e-mails.
it is not perfect, it lacks features, but it have [almost] all features I needed.

> Strange, - why have the Thunderbird developpers not found a solution 
> for years if the solution exists? Thank you for this hint.

Reason is simple. Read comments #30 and #31.
 
> There is a tiny flaw though. The "font-style" dropdown indicates "Variable
> width" and this made me worry the first 2 or 3 times I composed a new message.

I thinking about replacing this two controls by my versions, specialized to use <span> and CSS instead of <font> like original code does. 
In this case I will also be able to update this controls according to current style under caret.

> But I verfied the result: the recipient gets the mail with the correct style
> and with the correct size. 
 
> It is irritating if the preferences you set via Tools > Options do not take any
> effect because an extension is predominant. 

Why? 
I designed Stationery specifically to override such defaults. 
There some special markers in template code to place signature and cited text in specific places of template. There is also code to position caret.
This way I can have very proffesional looking emails, and every template can have different fonts and colors. Taking TB defaults into account is too much work for [almost] insignificant effect.

TB defaults are used if You select "without Stationery" pseudo template.

Anyway, for more info or discussion just e-mail me.
Blocks: 558280
Hi,

I've the same problem than explain.

Thunderbird don't use default font prefs when using list and don't restore it after closing a list.

Best Regards
Sorry, Guys - but i've tried now about 2 hours with config the stationary addon, and will give up now. I also Emailed to arivald and figgs and hope they are able to help me. 

I just want to send all outgoing Emails with white paper, black colored text in Verdana. The size is what makes me going crazy.

My old (on XP-Machine) Outlook Express say's (in hmtl-View):
...
<FONT face=Verdana size=2>
....

But with size "2" setted in stationary html it will not work (much to small). And "Small" will be interpreted by OExpress (most of my reveivers uses Outlook) as size 12!? 
What can i do, that Outlook Express will recognize and respect received mails from me as Verdana 10?
Although this is not a Stationary discussion forum, but this is what I now use (with some help from Arivald to place the cursor correctly when using the tab key):
<div  bgcolor="#ffffff" text="#333333" style="font-family: Garamond, serif; font-size:12pt;">
<span id="_AthCaret"><!-- initial cursor placement -->cursor</span>
<br><br>Groeten, Kind regards,<br>Alte</div>
FUNTASTIC! Thanks - every of my questions are now answered (additional the not asked about the cursor, thx. Alte de Boer!). Stationery works great and is more than a normal "workaround" for me. Thanks to all.
Since 1.1.19 works fine as far as this font bug is concerned, why couldn't it be changed into  SM 2.0x with the appropriate security fixes until the SM 2 font problem is solved.

Does this not make sense?
Any status or updates on this bug? Any chance for 3.1?
http://www.mozillamessaging.com/en-US/thunderbird/3.1b2/releasenotes/#issues

Stationary is not a solution - fails for replies and other situations.
(In reply to comment #159)
> Any status or updates on this bug? Any chance for 3.1?
> http://www.mozillamessaging.com/en-US/thunderbird/3.1b2/releasenotes/#issues
 
Are You nuts? This bug has only 6 years... is too early to fix it ;-)

> Stationary is not a solution - fails for replies and other situations.

How it fail for You? 
For me it works as expected. 
You may mail Me (arivald@interia.pl), and descibe what is not working or working wrong. I'am always open to ideas how to extend my extension. Thanks in advance.
(In reply to comment #159)
> Stationary is not a solution - fails for replies and other situations.
The Stationary Add-on is working fairly well for me. It works with <div> ... </div> and I think this is exactly the approach for a final solution to this bug.
(In reply to comment #159)
> Stationary is not a solution - fails for replies and other situations.

I feel more and more comfortable with the Stationary Add-on. Since I have added some improvements to my template, it works almost perfect. I have not encountered any situation Stationary fails ever since. I even got rid of my various signatures and replaced them by different Stationary templates. Compliments and thanks to arivald@interia.pl.

Here is the HTML code of the default template I use and I am very happy with it:

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
  <head>
    <style type="text/css">
      html, body, p, ul, ol, table, tr, td, #text {
        font-family: 'Trebuchet MS', sans-serif; 
        color: #000080; 
        font-size: small;
      }
      #signature {
        font-family: 'Courier New';
        color: "#000080"; 
        font-size: small;
      }
    </style>
  </head>

  <body>
    <div id="text">
      <span id="_AthCaret"><!-- initial cursor placement -->Cursor</span>
      Hello ... <br />
      <br />
    </div>
    
    <div id="signature">
      -- <br />
      Kind regards<br />
      Put your name here<br />
      <br />
      put your address here if you wish<br />
      put your phone number here if you wish<br />
    </div>
  </body>

</html>
Bulleted list?

Just type your email and the font changes. That's why I still use 1.1.19, the last good SeaMonkey.
Previously, press the "End" key, clicking past the last line, or otherwise navigating to the end of a line while composing a message would cause the font to change from the selected font to "Variable Width".

In the "Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.1.10) Gecko/20100611 Lightning/1.0b1 Shredder/3.0.6pre" nightly and up, this no longer occurs.  What changed?  Maybe that change can be applied to fix the font change when inserting a numbered list.
I wish I had the knowledge to solve this problem. It is very perplexing.
(In reply to comment #166)
As a follow up...

When I open up a draft message for editing and navigate to the end of the message, the font changes to "Variable Width".  If there is a difference in how the Composer is initiated for a new message versus editing a draft message, perhaps that difference is important.
Test
I'm shocked that people have been reporting variants of this bug since 2004, and nothing has been done about it. I and others have been complaining about it on the Tb forum, hoping there would be a simple fix -- but clearly not.  See also bug 514265 -- newer, shorter, but much the same problem.

Tb3 has made the problem immeasurably worse. It now happens with almost
every single email I compose (reply or new), changing fount between one word and the next. Thunderbird has become almost unusable.

The general consensus of professional opinion here appears to be that this bug will never be fixed because the underlying code that Tb is written in is so scary that no one dares go there. If that is really so, as someone else pointed out above, it relegates Tb to the status of a "toy" email program, not fit for the real grown-up world.
(In reply to comment #171)
> I'm shocked that people have been reporting variants of this bug since 2004,
> and nothing has been done about it.

I'm also shocked that none of the people reporting this are looking in the code and doing something about it. You know, change in an open source project usually only happens when someone who has a problem with some functionality actually digs in and creates a patch. Nobody is being paid for working on this code because nobody is paying for using this code, so whoever has a problem with how it works should better go and volunteer his own time to work on it and come up with a way to fix it.

That said, please read https://bugzilla.mozilla.org/page.cgi?id=etiquette.html and only comment here if you have something to contribute to help fixing this bug, as it's becoming harder and harder for someone who actually wants to fix it to actually find the comments he needs to read for doing so.
Robert, as a user I was doing my duty in reporting details of a serious fault in Tb, and adding my plea for something to be done about it. Is that wrong? If the programmers aren't told that the problem is much worse in Tb3 they'll continue to ignore it.
As for "looking in the code and doing something about it... better go and volunteer his own time to work on it", not all of us are programmers. Some of us are just users who are now finding Tb, especially Tb3, unusable. Please don't tell us off for saying so.
Does not depend on bulleted lists. Font size selected in Preferences changes unexpectedly during regular typing within a given paragraph (i.e. does not depend on manual paragraph break or carriage return either.) Thunderbird 3.1.2 running on WinXP SP3 on well-maintained Dell box.
Makes no difference if you select plain text or HTML. Result is the same.
robert, not all of us our programmers with the capability to fix such bugs on our own. Even if we were programmers, the time required to learn enough 'context' to fix such a one-off bug is disproportionately large.

Having said that, I agree that other people working on thunderbird are not necessarily getting paid for their time. This can be fixed.

If a developer can give an estimate of time & money required to fix this bug, I'll pay up if it's within my means. If it's not, I'll pay whatever is possible and let other people complaining about this bug do their bit.

How does that sound?
I'm with Saurabh Nanda and I will personally offer up $150 towards a working solution.
A hundred dollars here.
Attachment #422007 - Flags: review?(philringnalda)
If anyone ever does write a patch for this *with a test,* feel free to file a duplicate and put the patch there.
Disgusting, isn't it?
I wish I was smart enough to solve this problem.

Apparently I'm not the only one. No one else has ever been.
URL: http://gsfn.us/t/15jkn
Whiteboard: [see comment #82] → [gs] [see comment #82]
The current "URL" of this bug points to a duplicate GetSatisfaction issue report. Creating a duplicate issue (with a very poor Subject line) will only serve to dilute the perceived importance of this critical issue. Could someone please correct the "URL" in this bug to point to the correct GetSatisfaction issue report (i.e., http://getsatisfaction.com/mozilla_messaging/topics/font_markup_problems_in_the_compose_message_window)? Thanks!
BTW: Everyone, please go to the GetSatisfaction issue report[1] and click on "I have this problem too"! We can probable make this the Thunderbird issue #1 that way[2].

[1] http://getsatisfaction.com/mozilla_messaging/topics/font_markup_problems_in_the_compose_message_window

[2] http://getsatisfaction.com/mozilla_messaging/problems/common
What happened to the plan of people contributing money to fund this bug fix? Is there a developer out there who knows how to fix this bug? If he/she can post a short plan & timeframe people can start putting money into an escrow account.
Start the escrow account. I am willing.
(In reply to comment #184)
> BTW: Everyone, please go to the GetSatisfaction issue report[1] and click on "I
> have this problem too"! We can probable make this the Thunderbird issue #1 that
> way[2].
> 
> [1]
> http://getsatisfaction.com/mozilla_messaging/topics/font_markup_problems_in_the_compose_message_window
> 
> [2] http://getsatisfaction.com/mozilla_messaging/problems/common

I did it. Thanks.
I don't understand the getsatisfaction.com business.  Is that an official reporting venue that the Mozilla Tbird developers respond to?  Or is it just a third party "put your gripe here" site?  I thought THIS (bugzilla.mozilla.org) was the official place for bug reports. ???
(In reply to comment #188)
> I don't understand the getsatisfaction.com business.  Is that an official
> reporting venue that the Mozilla Tbird developers respond to?  Or is it just a
> third party "put your gripe here" site?  I thought THIS (bugzilla.mozilla.org)
> was the official place for bug reports. ???

Don't know but it is another place to express our dissatisfaction with an email client that used to work in it's previous version and doesn't now. Need help and we want the world to know.
(In reply to comment #188)
> I don't understand the getsatisfaction.com business.

Go to http://getsatisfaction.com/mozilla_messaging and look on the right:

"Message from Mozilla Messaging
Welcome to Mozilla Messaging's Get Satisfaction site, home of Thunderbird support and support for other Mozilla Messaging products."

Also read https://wiki.mozilla.org/Thunderbird/Support/GetSatisfaction/README
So I think that this is not the right place to get a bug solved. I try to post on the development mailing list. This is my post:
http://groups.google.lk/group/mozilla.dev.apps.thunderbird/browse_thread/thread/bd4722015d7af986#

Also Peter Lairo asked many times to fix this bug
http://groups.google.lk/group/mozilla.dev.apps.thunderbird/search?group=mozilla.dev.apps.thunderbird&q=250539&qt_g=Cerca+in+questo+gruppo
If more people will ask. May be we get answered!

 
This is the plan for the next Thunderbird version (I think 3.2)
https://wiki.mozilla.org/Thunderbird:Thunderbird_Post_3.1_Plan
I hope that this bug will be addressed here!


Alfonso Martinez made an extension that integrate FCKEditor with Firefox, may be someone can implement the Thunderbird extension.
https://bugzilla.mozilla.org/show_bug.cgi?id=539299#c1
I pray that the problem will be solved.

I use SeaMonkey, not Thunderbird but the problem appears there as well.
(In reply to comment #192)
> This is the plan for the next Thunderbird version (I think 3.2)
> https://wiki.mozilla.org/Thunderbird:Thunderbird_Post_3.1_Plan
> I hope that this bug will be addressed here!

I added a comment there. See:
https://wiki.mozilla.org/Talk:Thunderbird:Thunderbird_Post_3.1_Plan
Good Peter,

I hope others here will do the same thing.

Bye Massimo
It appears to me that this is an editor bug.  If someone can create a test case as an HTML file and file a bug in Core::Editor, I may try to sneak a fix in for Gecko 2.0.
Depends on: 590640
I'm really happy that something is moving, but which version of Thunderbird will be based on Geck0 2.0?

Thank you Ehsan!

(In reply to comment #196)
> It appears to me that this is an editor bug.  If someone can create a test case
> as an HTML file and file a bug in Core::Editor, I may try to sneak a fix in for
> Gecko 2.0.
For who is interested to know the status of the Editor bug filled by Ehsan -->
https://bugzilla.mozilla.org/show_bug.cgi?id=590640
Thanks Malix
Someone is working on external editor integration 
https://bugzilla.mozilla.org/show_bug.cgi?id=539299
so for example FCKEditor http://ckeditor.com/ can be used.
Let's all discuss it here:
http://mozillalabs.com/messaging/2010/09/03/2756-bugs-found/

Then let's just get rid of the editor problem all together.  I guess its time to let it die, and bring T-bird into the 21st century by helping it work more efficiently in a more modern context.
(In reply to comment #201)
> Let's all discuss it here:
> http://mozillalabs.com/messaging/2010/09/03/2756-bugs-found/

That link is a good data point, but I'm not sure a linear non-threaded blog post is the best place to discuss this complex issue. I suggest discussing in the Thunderbird developer newsgroup:

news://news.mozilla.com:119/mozilla.dev.apps.thunderbird

(Please take the time to subscribe to the newsgroup, since mailing lists *often* break the threads)
An observation from a wall-hugger...
- Numerous bugs describe various manifestations of one issue (composer is ****).
- This bug is assigned to nobody.
- Various people are working on it (from different angles) at various levels of spare time (e.g., Ehsan Akhgari, Jonathan Protzenko, et. al.)
- It is being discussed in disparate forums all over the place.
- There is no consensus yet toward the best way to solve a hard problem.

Much of this perhaps is just the nature of community-based, open-source software development.  To me, it seems this model simply does not handle really hard, complex, involved issues very well.  There is no single person or group to make decisions and say "go this way."  Thus, floundering around without focus ensues.  I don't see how a focus on "this is the way we're going to fix it; you, do this; you do that" ever happens.  I hope I am wrong and just am missing an understanding of how community-based, open-source collaboration solves huge problems.  If there IS a way, it needs to be applied here.
Thanks, Peter (#202).  I'm not convinced that a mailing list is as good as even some sort of IM.

Thanks also to "wall-hugger" (#203).  Very astute observation, and one that deserves a lot of consideration.  I, too, feel this way and have found little interest in solving this one problem with Internet-based communication.

With the proper forum type, this problem could be worked out very quickly.  Anyway, that's my two cents.
If I may put in my two cents, to those people saying that the problem is with using the <font> tag instead of CSS, you're wrong.
CSS requires tags too, so you wouldn't be solving the problem this way.
For example, where the code currently generates
<font face="Arial">Arial</font>
you'd have to generate
<span style="font-family:'Arial'">Arial</span>
and the end result (with regards to this bug) would still be the same; you can still position the cursor outside of the span. It doesn't help. the solution lies elsewhere.

Not that I would mind seeing the <font> element go, though...
I think that this bug will never get solved. After getting some attention back in august and september, now everything is again sleeping.
Work Jonathan Protzenko is at a standstill since September 10 https://github.com/protz/Compose -- https://bugzilla.mozilla.org/show_bug.cgi?id=539299
And the same happen to Ehsan Akhgari https://bugzilla.mozilla.org/show_bug.cgi?id=590640
The truth is that all efforts of Mozilla are concentrated on Firefox and they don't have considration to others users. But I think that they can't no more ignore a 6 years old bug (https://bugzilla.mozilla.org/show_bug.cgi?id=250539) that receive 207 comment. And also this thread. I hope that Roland Tanglao wil clarify the situation.
The truth is that all efforts of Mozilla are concentrated on Firefox and they don't have considration to others users. But I think that they can't no more ignore a 6 years old bug (https://bugzilla.mozilla.org/show_bug.cgi?id=250539) that receive 207 comment. And also this thread (http://getsatisfaction.com/mozilla_messaging/topics/font_markup_problems_in_the_compose_message_window?utm_content=topic_link&utm_medium=email&utm_source=reply_notification). I hope that Roland Tanglao wil clarify the situation.
Leaving useless comments which do not help in fixing the bug in any way will only make it harder for developers to fix a bug.  I'm removing myself from the CC list because I haven't seen a single useful comment here since I added myself to the CC list.
Malix: I understand that you're frustrated that some bugs aren't fixed as quickly as you might hope.  That's entirely valid, and I suspect that frustration is shared by others as well.

That said, as we've just seen, venting your frustrations in Bugzilla actually tends to make developers less motivated to fix the problem, rather than more.  This is particularly painful in the case where the developers are working in their spare time.

Please review <https://bugzilla.mozilla.org/page.cgi?id=etiquette.html> before commenting further in Bugzilla bugs.
Dan, I don't make only negative comments. In the past I help to fix a bug https://bugzilla.mozilla.org/show_bug.cgi?id=311956. But this bug is realy annoying and got attention last time that more people are commenting, now is again sleeping. What happened to Ehsan Akhgari patch? Has someone made a test to it? How  can we test it? Is this patch breaking the CKEditor? Mark Banner https://bugzilla.mozilla.org/show_bug.cgi#c7 said that you are esperimenting togather but we have no feedback. How we can know the overall progress of the fix? I try the Jonathan Protzenko extension but this completely replace the editor and I lose all the standard functionality, for me this is not acceptable.
On similar threads to this there's been information about an add-on which solves this issue: QuoteAndComposeManager. It's available at http://nic-nac-project.org/~kaosmos/realborders-en.html. Install, then go to Options and tick "Stabilize predefined font" in the Font tab.
It works.
Thunderbird is usable again.
Thank you "kaosmos"!
Thanks for the info.  I want to try QuoteAndComposeManager but can't activate it in TBird!  Downloaded it and also Megazipper to be able to open the XPI file. Saved both in a folder. Opening QACM just opens Mega zipper.  No way yet discovered to activate it (or parts)of it in TBird. Nothing new appears in TBird Tools>Options and nothing about extensions there.

If there is a remedy for the one fatal flaw in TBird it would be helpful to know how to install it.
I had a similar problem, and emailed Paolo (kaosmos) through his page.  He replied within minutes pointing me to http://kb.mozillazine.org/Extensions_%28Thunderbird%29 which tells you how to do it.

Go for it -- it works!
(In reply to comment #119)
> (In reply to comment #118)
> 
> > But then again, I don't really know much about editor.
> > And yes, the patch is very much incomplete. I know that. I just don't think
> > that working on it makes sense until we agree it the approach is the right one.
> 
> I am an editor peer and that's why I can say this is an editor core bug. Nvu
> and BlueGriffon have the same issue and I have to solve it for BlueGriffon
> anyway.
> 
> > (btw, I think that using <span> and css would be really the right way, but I
> > don't see how to do that...)
> 
> Using css in email messages raises other issues: some email clients choke on
> that. Interoperability of composed "rich-text" messages among UAs is a major
> item that often transcend "purity" wishes, unfortunately...

I know that there was FLAMES and those discourages developer. But after patch was proposed, nothing is moving again and so another one year and half is gone. What happen? Why patch never get tested? Why noone try to fix this very old, old bug?
Every month a lot of people comment on http://getsatisfaction.com/mozilla_messaging/tags/bug_250539 , this mean to me that we are really interested to a fix and maybe not interested on new features.
Of course we users are interested in real progress being made.  Sadly, the people in charge of Mozilla's outreach to the users are not very professional.  You'd think that dealing with disgruntled users would be par for the course, but these people have no such level of concern for others' feelings.  They take everything as a personal attack, when they should know that the users have no way of knowing who they are, nor should they care.  They've lost their salesmanship, and so they've lost their desire to communicate what is going on with the very people they claim to serve.

It is all very sad.
So, from the comments over at Get Satisfaction on the new TB 5 beta, it appears from the users who have tried the TB5 beta...  are you ready for this...  the bug is STILL THERE!  Wow...  Another major release coming up and still the same old **** compose bug so one cannot reliably compose an HTML email message with uniform font throughout the message.  This bug was originally opened in 2004, and now it is 2011 and we still have the same issue. Amazing.
Version: 3.1.9
Operating System: Microsoft Windows XP

The following actions cannot honour "default font = fixed width":

- New Paragraph (pressing Ente)
- New Table (maybe List, too)
- Reply E-mail.

Please test the above three actions.

The Yahoo! Web page e-mailed also has a similar problem,
maybe less serious.
The Lotus Notes e-mailer (a Microsoft Windows application)
also has a much less serious problem after you press Enter.

I wonder wheter it may be a problem with third-party HTML/Richtext editor,
which is not developed by Mozilla Thunderbird.

How can we help them solve it?

Thanks.
Finally i ditched TB and switched to PostBox because of this. Postbox is not perfect, and has its own issues, but development listens, and fixes are not taking years and years.....
The "URL" to the GetSatisfaction issue is no longer valid. Could someone please edit the URL to read:

http://getsatisfaction.com/mozilla_messaging/topics/font_markup_problems_in_the_compose_message_window

And make sure to VOTE for that issue!

BTW (not *directly* related to this bug): I think I found the "reason" (i.e., excuse) this bug is being ignored:

http://mozillalabs.com/messaging/2010/09/03/2756-bugs-found/

http://blog.xulforum.org/index.php?post/2011/08/18/Dealing-with-users

I can accept the idea of replacing the editor (if done right, and if not left abandoned. I find it infuriating that the Thunderbird devs aren't all over this issue). I do not like the direction the "Conversations View" is going. My partial opinion on the latter issue is given here:

http://getsatisfaction.com/mozilla_messaging/topics/user_chosen_font_e_g_arial_is_not_respected_while_writing_e_mails#reply_6700762
(In reply to Peter Lairo from comment #226)
> The "URL" to the GetSatisfaction issue is no longer valid. Could someone
> please edit the URL to read:

I disagree that it is invalid, but please ask Roland before making a change.

> I can accept the idea of replacing the editor (if done right, and if not
> left abandoned. I find it infuriating that the Thunderbird devs aren't all
> over this issue).

This is generally getting off-topic, however, as we're here due to the url issue... We are currently looking at getting this issue resolved, however we have generally lacked the experience to fix bugs in this area and have needed to focus on other things, hence why this bug has remained as helpwanted. We may now have someone who is looking into this area, but I can't yet give any timescale as it is too early to say.

> I do not like the direction the "Conversations View" is
> going. My partial opinion on the latter issue is given here:

That is totally off-topic. Please restrict bugs to on-topic conversations that work towards fixing the issue as per the etiquette.
Flags: wanted-thunderbird3?
@Peter Lairo,
Sorry about the problems you are experiencing.  But I can share my findings with you about the problem, and it may help to lend some light on how things are done.

When dealing with the FOSS (free and open source software) community, we have to remember that the people who are working on the "project", are doing so part time as a sort of hobby effort.  They are working without pay, and they are doing their contribution, whatever it might be, to satisfy their own desires and at their own pace.  If others find some benefit in their work, so be it, but we cannot complain about their personal projects since they are doing things the way they want it done.  I think we can all understand that and appreciate it.

I didn't get that for a long time.  We have to remember that programs like Mozilla are not like commercial software.  The reasoning behind putting FOSS programs out there are often very difficult to fathom, so we should not be concerned with the reasons.

One confusion that is made by us "newbies" is that we misinterpret the promotion of Mozilla products by that foundation as meaning the same thing as promotion by the commercial companies.  It does not.  One is promoting their philosophy and the other is promoting a product for profit.

If we wish to find really good software that works they way we personaly desire, we need be willing to pay for it and only then can we demand performance.  And if you still want to use Mozilla software, you just have to wait and hope that something comes about in the way you want.  (I do realize that sometimes personal productivity does not allow us the time to wait.)

I hope that explains things a little and takes the pressure off of those who do not want to be dealing with these issues.

Thanks for your understanding.
(In reply to KitchM from comment #228)
> @Peter Lairo,
> Sorry about the problems you are experiencing.  But I can share my findings
> with you about the problem, and it may help to lend some light on how things
> are done.
> 
> When dealing with the FOSS (free and open source software) community, we
> have to remember that the people who are working on the "project", are doing
> so part time as a sort of hobby effort.  They are working without pay, and
> they are doing their contribution, whatever it might be, to satisfy their
> own desires and at their own pace.  If others find some benefit in their
> work, so be it, but we cannot complain about their personal projects since
> they are doing things the way they want it done.  I think we can all
> understand that and appreciate it.
> 
> I didn't get that for a long time.  We have to remember that programs like
> Mozilla are not like commercial software.  The reasoning behind putting FOSS
> programs out there are often very difficult to fathom, so we should not be
> concerned with the reasons.
> 
> One confusion that is made by us "newbies" is that we misinterpret the
> promotion of Mozilla products by that foundation as meaning the same thing
> as promotion by the commercial companies.  It does not.  One is promoting
> their philosophy and the other is promoting a product for profit.
> 
> If we wish to find really good software that works they way we personaly
> desire, we need be willing to pay for it and only then can we demand
> performance.  And if you still want to use Mozilla software, you just have
> to wait and hope that something comes about in the way you want.  (I do
> realize that sometimes personal productivity does not allow us the time to
> wait.)
> 
> I hope that explains things a little and takes the pressure off of those who
> do not want to be dealing with these issues.
> 
> Thanks for your understanding.

I can not agree with you because someone in the past try to fix this bug but abbanoned to work on Firefox. Mozilla promoted Thunderbird as first class application but this let me think that wath they say is not true
(In reply to Mark Banner (:standard8) from comment #227)
> (In reply to Peter Lairo from comment #226)
> > The "URL" to the GetSatisfaction issue is no longer valid. Could someone
> > please edit the URL to read:
> 
> I disagree that it is invalid, but please ask Roland before making a change.
I think we can all agree that http://getsatisfaction.com/mozilla_messaging/tags/bug_250539 is the correct Get Satisfaction URL since it points to Get Satisfaction topics that affect this bug including http://getsatisfaction.com/mozilla_messaging/topics/font_markup_problems_in_the_compose_message_window which is the URL that Peter mentions
@Malix,
Someone, probably other than the workers on the project, may have presented a patch, but it could have just as well been rejected by the project.  Everyone is free to present patches, but that does not mean they will be accepted.

Regarding the issue of "promotion", that was part of my point initially.  No one should confuse the type of "promotion" that a company like Mozilla does with the that of a for-profit company.  Anyone may make any claim in this world, and that does not mean it is correct or that we all understand such claims in the same way.  There are many reasons why someone or some group would promote themselves and/or their product or services.  They are not all beneficial reasons.  Caveat Emptor; Let the buyer beware.

We'd probably best stick with the issue here as the Mozilla people lay it out and not get off topic any longer.  Thanks.
Everyone, please relax.  I'm working hard to work out a solution to this bug.  We are well aware of this issue, and comments which do not discuss the solution to this problem are *not* welcome here.  Please see <https://bugzilla.mozilla.org/page.cgi?id=etiquette.html>.
I understand that rewriting the editor from the scratch is a very hard work.
In the meantime, could be a solution to wrap all the body message in a div with a style attribute that fixes font-size and font-family?
This is the method used by QuoteAndComposeManager extension (not exactly, but this is the idea).
It's simple and should work always.
At the present every mail client or webmail should support style, so I guess that it doesn't give any compatibility problem.
In reply to comment #234 I suspect this will only work in special cases for reasons mentioned before.

My understanding is that this bug relates mainly to cursor position in relation to tags combined with the difficulty of determining the 'best' result when incomplete rich text is pasted from elsewhere. This would not be a trivial problem to resolve in a modern clean single HTML document and is much more complex in core especially with the added complications of historic mail interoperability.

Several well meaning remarks give the impression that css can be used to enforce a style on a document. I doubt that, in general, this is so although Mozilla styles often make use of 'important' which can go some way towards this.

My experience is that many alternative products which give the impression of handling HTML editing well make quite a mess of the css/HTML. This was so with most MS products for many years although I have not looked recently. Some versions of FirstClass made an even bigger mess.

Is there a simple developers' description of this bug together with a list of the items which probably need patching? Are there any patches which we can test?
(In reply to Neville Hillyer from comment #236)
> In reply to comment #234 I suspect this will only work in special cases for
> reasons mentioned before.

I don't understand that.
All email clients or webmails I know supports style.

The problem is caused by the fact that sometimes the cursor falls out from the <font> tags, used to stylize the text by Thunderbird

If you've a code like this

<div style="font-family:arial; font-size:12px">

.... all message body .....

</div>

also if the cursor falls out, the style is kept.
Maybe it will not work at 100%, but it will surely at 98%, that is a good result with a little effort and a clean code.
In reply to comment #237

I suspect that most email clients do not support style although most people use a client which does - there are many historic text only clients. Clients normally transmit both HTML and text and users decide which they want. I prefer text. If necessary clients do their best to convert HTML to text if the text part is missing.

My understanding is that the body div solution does not work too well if signatures are used and can also fail if text with its own tags is imported into the middle of the div. I am not sure what happens if invalid HTML/css is imported - ie without opening or closing tags etc. It appears to me that the success rate will be much less than 98% and not acceptable to developers/testers.
i am reading this with much interest, but must  say I am a bit confused.  If it is so hard, why is it that QuoteAndComposeManager can do it so successfully using similar techniques to what is being discussed?
Please be aware we're actively looking at getting this bug fixed and work should progress soon, but at this time I have no ETA.

Extra debate/comment isn't actually that helpful at this stage and we will ask for more help/ideas/testing when we need them.

(In reply to fm_mozbugs from comment #239)
> If it is so hard, why is it that QuoteAndComposeManager can do it so
> successfully using similar techniques to what is being discussed?

From what I've seen that is providing a rough workaround to the issue and not fixing the core issue that is present.
(In reply to Mark Banner (:standard8) from comment #240)
> Please be aware we're actively looking at getting this bug fixed and work
> should progress soon, but at this time I have no ETA.
> 
> Extra debate/comment isn't actually that helpful at this stage and we will
> ask for more help/ideas/testing when we need them.
> 
> (In reply to fm_mozbugs from comment #239)
> > If it is so hard, why is it that QuoteAndComposeManager can do it so
> > successfully using similar techniques to what is being discussed?
> 
> From what I've seen that is providing a rough workaround to the issue and
> not fixing the core issue that is present.


It has only been an ongoing bug for 7+ years [Assaf Urieli 2004-07-09 02:41:36 PDT - Build Identifier: version 0.6 (20040502)].  Don't forget all the similar bugs filed that have been cornholed here.  

Seriously, what is the hurry?  Why don't you wait another 4 or 5 years before it is really an "important" bug.  Having your outgoing email look like **** is a "feature".
@Wolf Thunder,
True enough, and I sympathize.  But we must not forget that this is someone else's hobby.  In the FOSS (free and open source software) community, users may not make any demands on the programmers who do this for free and as they feel the desire.  Mozilla's promotion of its products appears to be more for self promotion than altruistic reasons, and that is their right, so we must not see such "advertising" as promoting a program's capability for a user's needs.  The FOSS community owes no one anything.

While your observations appear correct, we users should just get used to the way things are.  We need to lower our expectations, unless we are willing to learn a programming language and create our own software.  Or purchase serious commercial software.

I recognize that this sounds harsh, but such is our world.
All of a sudden, today when I replied to a couple of emails, the font size of my reply was huge! When I clicked on "Reply" the reply form showed up in normal size, but then in less than a second it changed to the large size. Weird!

Settings: Body Text  &  Variable Width 

Except for deleting a bunch of outdated emails, I hadn't changed anything beforehand.
(In reply to hamiglorr from comment #245)
> All of a sudden, today when I replied to a couple of emails, the font size
> of my reply was huge! When I clicked on "Reply" the reply form showed up in
> normal size, but then in less than a second it changed to the large size.
> Weird!
> 
> Settings: Body Text  &  Variable Width 
> 
> Except for deleting a bunch of outdated emails, I hadn't changed anything
> beforehand.

Postscript:

Downloaded Thunderbird 8.0 - Font still changed to larger size when I reply to an email.

Went to Thunderbird > Preferences > Display > Formatting > Fonts Advanced  and fiddled around with settings; Font is now stabilized at the correct size when I reply or write a new email.
This problem is an ongoing pain, the last activity appears to have occurred two years ago.

Why are new versions being produced while the old problems remain?

Colin W.
@Colin W.
I share your pain.  However, please note that this bug remains unassigned (see at the top).  Also note my previous comments to help you understand why this will probably not be fixed.  Sorry.

The root cause is most likely the bad editor which was chosen to be encoded into the product.  But because of the lack of modularity and/or code complexity, a better editor cannot be simply plugged in.

We must wait patiently for whatever the owners decide they want to do for their product.  They may wish to bring new "features" or work on only a particular part or build a completely new product.  Ours is not to question why.  We must wait and see.

Hope that helps some.
Probably part of the Bug mentioned above, but unsure.
Using Thunderbird 10.0.1
When I open a new Write Message which has a signature attached, the first blank line of the message area indicates the default font set in tools > options > display > formatting, is used.  
However, if I move the cursor down to the next line; using the downward arrow on the keyboard (not return button), to the line which has the -- prior to the signature and then move the cursor back up, the selection has changed to Variable Width.

Should I start a new bug or is this part of the same issue, which has been going on since 2004 ?  Please confirm if this needs to be a new bug.
I'm new to reporting bugs, but it does seem odd that this composition editing bug is still around after all these years. 
Any updates on progress?
It is the same bug.  ANY cursor move will move the cursor past the hidden html tag that sets the font.  If you then try to move it back, it still sits at a point AFTER the hidden tag, so the font is thus changed.
Depends on: 756984
This bug has been fixed by bug 590640 and will be released in Thunderbird 15. Thunderbird 15 is currently in preview on in the Earlybird channel and is available from here:

http://www.mozilla.org/thunderbird/channel/

The only outstanding known issue with formatting is bug 756984. As such, I am therefore marking this bug as fixed.

If you find any issues other than bug 756984 in Thunderbird 15.0a2 or later, please file a new bug rather than commenting here. This will ensure your comments don't get lost and your issues are tracked.
Status: NEW → RESOLVED
Closed: 12 years ago
Keywords: helpwanted
Resolution: --- → FIXED
Whiteboard: [gs] [see comment #82] → [gs][fixed by bug 590640][see comment 259]
Target Milestone: --- → Thunderbird 15.0
Any chance of updating TB 3 for those who have a PPC Mac?
(In reply to Neville Hillyer from comment #260)
> Any chance of updating TB 3 for those who have a PPC Mac?

Sorry, TB 3 has been unsupported since December 2009 and has known security issues. Additionally, it would not be worth us doing the work for the small amount of users on that platform which would also have a good chance of breaking extensions.
There have been Thunderbird 3.1 releases this year. See the following:

RELEASE NOTES
v.3.1.20, released March 12, 2012
The Thunderbird 3.1.x series will no longer be supported from April 24, 2012. Beyond this date, security and stability will not be guaranteed and the Thunderbird 3.1.x series will become more exposed to Internet security threats.

The following link is for the considerable number of people who need old versions:

ftp://ftp.mozilla.org/pub/thunderbird/
(In reply to Neville Hillyer from comment #262)
> There have been Thunderbird 3.1 releases this year. See the following:

This discussion isn't appropriate to bugzilla. If you want to discuss more, please discuss on the tb-planning mailing list or with me direct.
TenFourBird 10.0.5 is available for Mac PPC
http://en.sourceforge.jp/projects/tenfourbird/
"Unofficial Mozilla Thunderbird build for PowerPC Mac OS X based on TenFourFox."
Thank you so much for this bug fix!  Unfortunately, my major annoyance encounter is the one in bug 756984.  I hope whoever the genius was who fixed this one will take a look at that one as well.
(In reply to Mark Banner (:standard8) from comment #263)
> If you want to discuss more,
> please discuss on the tb-planning mailing list or with me direct[ly].

Or, if you don't like mailing-lists and prefer newsgroups, you can discuss it in mozilla.dev.apps.thunderbird

news://news.mozilla.com:119/mozilla.dev.apps.thunderbird

PS. IMO, this bug is the most important fix for Thunderbird in the past five years. Thank you!!! Whoever fixed this should be named "Bug Squasher of the Year" and given the technical leadership of Thunderbird.
Is there any way to tell when this will appear in the full release (not Earlybird or Beta)?
(In reply to maybe-the-one from comment #267)
> Is there any way to tell when this will appear in the full release (not
> Earlybird or Beta)?

Just read this pages it's says 15.0 - so that's when it's going to be in "final".
Since Mozilla has just announced that it discontinues Thunderbird development, will there be a version 15 or will this be fixed in another way?
(In reply to Ami Yo. from comment #269)
> Since Mozilla has just announced that it discontinues Thunderbird
> development, will there be a version 15 or will this be fixed in another way?

Please read the blog post fully:

http://blog.lizardwrangler.com/2012/07/06/thunderbird-stability-and-community-innovation/

New Thunderbird development has been stopped by Mozilla, but may be undertaken by the community. Thunderbird has not been discontinued.

There will be a Thunderbird 15 version (and more), and that will include this fix.
Any idea if this is going into version 16 (and 17) and if sooner rather than later?

Thanks
Mark wrote version 15 (TB Stable is now at 14.0), so obviously it will be in 16 and 17...
Thanks Ami - I am using TB 16a2 from a day or so back but did not see this patch implemented in there yet unless I missed something - but look forward to when it is in place.
I am not sure if the patches for this bug apply currently to 16a2 but for yesterday's 16a2 I still have a problem with the following test:

1) Compose a new mail and type several lines of text into the main body of the mail.
2) Highlight all of the new text in the compose window.
3) Select Format->Size and increase the size to extra large.
4) Now (realising you want to add some more text) click in the middle of the text area and type in new text, and edit some of the text already there.
5) Nothing seems wrong at this stage but if the mail is sent then sometimes it seems to be fine in the copy that is actually sent, as confirmed by what appears in the copy in the Sent folder, but sometimes the font size is broken into sections of different sizes despite it all looking uniform at the point the Send button is about to be clicked.  This seems to have been the case for some time.
(In reply to Mike Cloaked from comment #274)
> I am not sure if the patches for this bug apply currently to 16a2 but for
> yesterday's 16a2 I still have a problem with the following test:

As previously requested, please file a new bug for any issues that are found in versions later than Thunderbird 15. Please do not comment here, this is not necessary and your issue will likely end up being lost.
Whiteboard: [gs][fixed by bug 590640][see comment 259] → [fixed by bug 590640][see comment 259 - file NEW bugs for other issues][gs]
Resolved fixed? I'm using TB 24.3.0 and it is worst.

Now randomly font changes when typing.

When I have an automatic signature and I start to type the cursor jumps to the end, after the signature.

I don't remember what version had these "new" format problems first but the "old" ones were never resolved.

Mozilla/5.0 (X11; Linux i686; rv:24.0) Gecko/20100101 Thunderbird/24.3.0
I sympathize with you.

The reasons for the unassigned status and/or resolved/fixed status might include too many problems elsewhere, not an interesting issue, not as important as other issues or as important based upon number of complaints, or what have you.

Like a lot of us, programmers are usually not interested in one particular project for the long term.  They wish to move on to something new and stimulating.  Microsoft is the master of this view because they are a sales and marketing company.  The past does not matter, nor does the present because we need new things all the time.  I also understand that mindset.

However, as a user like you, I remember the ease of use of the early editions and I miss the simplicity and stability of them.  I would give a lot to have Mozilla freeze the code expansion right now and go thru it with a fine-toothed comb, simplifying, cleaning, and creating proper divisions in the code so that components can be swiftly and easily swapped out without continually creating new problems with ever increasing complexity.  It is truly getting to hard to diagnose.

I wish we could just pay for TB as commercial software and buy a version that will be dependable for ten years.  I am more than satisfied with existing features; only needing the ease-of-use and dependability built back in.

Still, we can't complain about free, I guess.
I wholeheartedly agree. It is a disease of software development everywhere, not just in Mozilla. Again and again I find applications with a host of features 99% of which I shall never use, but which fail in their primary function. And not only in software. Even in new cars, which have so many computerized and other features on and off the dashboard that one might as well just sit in the car outside one's home and try to make it all do whatever it is supposed to do instead of driving somewhere.
(In reply to KitchM from comment #278)
> I would give a lot to have Mozilla freeze the code expansion right now and go
> thru it with a fine-toothed comb, simplifying, cleaning, and creating proper
> divisions in the code so that components can be swiftly and easily swapped out
> without continually creating new problems with ever increasing complexity.

If you followed Thunderbird development, you'd see that this is exactly what's happening. Lots of the recent changes have been in fixing long-standing bugs, improving performance, and replacing difficult-to-maintain components.

It seems the real complaint here is not that "bugs aren't being fixed", but "*my* bug isn't being fixed". However, complaining in a fixed bug isn't the way to get your issues addressed, especially given comment 275. To repeat:

> As previously requested, please file a new bug for any issues that are found in versions later
> than Thunderbird 15. Please do not comment here, this is not necessary and your issue will
> likely end up being lost.
@Jim Porter,
Since this bug iin not fixed and will not be fixed, and since the latest version is 24.3.0, sorry but I'm really not concerned with your opinion on this issue, and I do not think it is appropriate or germane to the issue.

My comments were meant to be helping people see how they and their usage fits within the overall picture of the TB program, and how to have a more realistic viewpoint on the subject, plus trying to sympathize and offer support to their position.

"My" bugs are rarely, if every addressed, so your comment doesn't apply there either.

The actuality is that TB has never run worse in recent history, and that new bugs are popping up all the time.  This fact alone speaks volumes against your idea of any improvements that some may think they are doing.

I hope we users can still be allowed to converse and commiserate amongst ourselves on this issue.
This HTML composition bug is at least 15 year old, and keeps getting shuffled aside, reassigned, moved to new id's, "resolved", etc.  The whole thing is a joke.  People who work on it never fix it...

And I concur, each new release is worse with new issues cropping up.

I am not filing a new bug under a new ticket of version 15 and newer.  I reported this bug back at release 1 or 2....

Pathetic.
Thunderbird is an email client.
Email clients are used to receive and read emails...
and to compose and send emails.

That latter, FUNDAMENTAL function of Thunderbird has been broken for years--and still is. There are multiple symptoms (translate: multiple bug reports); whether there is really one root cause or they are independent is immaterial--the bottom line is that the font changes frequently, often, maddeningly, as emails are composed.  The FUNDAMENTAL function of composing emails does not work well at all, ending up generating emails that, at a minimum, reflect badly on the writer.  They look awful.

The only sensible approach would be for the Mozilla leads to direct a =total= focus of all developers,  on fixing the composer--or replacing it, and maintaining that focus until the job is done.  

The state of affairs is shameful.
(In reply to KitchM from comment #281)
> @Jim Porter,
> Since this bug iin not fixed and will not be fixed, and since the latest
> version is 24.3.0, sorry but I'm really not concerned with your opinion on
> this issue, and I do not think it is appropriate or germane to the issue.

The status on this bug report is "RESOLVED FIXED". I just now verified that this bug is indeed fixed in TB 24.3.0 by following the STRs in comment 0. If you have a *different* bug that appears similar, please file a new bug. This is not the place to track related issues. Even if you have the *exact* same issue as in comment 0, please file a new bug. Discussion on long-fixed bug reports is just going to get lost, and so any effort you spent will be wasted.

> "My" bugs are rarely, if every addressed, so your comment doesn't apply
> there either.

That's entirely my point. Despite your assertions that TB's quality has deteriorated, if you look at the commit logs, the majority of commits are fixes, many of which are for long-standing bugs. (There are also a bunch of UI polish fixes as well.) Relatively few commits are for new features. Since Thunderbird is open source, it's easy to verify this. There's even a blog that shows a list of recently-fixed Thunderbird bugs: <http://www.rumblingedge.com/>.

I can therefore only conclude that when you're talking about TB's quality, you're referring only to your subjective issues with the software and not with its objective quality (which is measurable by test coverage, etc).

> The actuality is that TB has never run worse in recent history, and that new
> bugs are popping up all the time.  This fact alone speaks volumes against
> your idea of any improvements that some may think they are doing.

Ok, prove it. Start filing regression bugs, or even better, help out by adding unit tests to ensure that we don't regress in the future. I've been tracking incoming bugs on this project for about 4 years now, and the number of new problems has dropped steadily. If you're finding an increased number of issues and aren't filing bugs, then don't be surprised if they aren't fixed. Not everyone uses the same parts of Thunderbird as you.

> I hope we users can still be allowed to converse and commiserate amongst
> ourselves on this issue.

If you plan to do so by violating Bugzilla etiquette, then no you may not. Bugs are not a discussion forum; they are a place for developers and QA to resolve issues. If you'd like to discuss Thunderbird  from a user perspective, there are plenty of places for you to do so, such as ssupport-thunderbird@lists.mozilla.org (aka mozilla.support.thunderbird).
Sorry, the email address in my comment should be support-thunderbird@lists.mozilla.org
I knew it.  Just rely upon outdated and unacceptable "rules".  "But we've always done it this way."

Then fall back on tech-speak that users don't understand and shouldn't need to.  "Regression bugs" and "unit tests" indeed.

And I absolutely hate it when someone calls my usability issues as "subjective".  It couldn't be more insulting.

Well, pardon me for existing.

But I'm not surprised.  Mozilla programmers are doing their own think and that is their right with their software.  We freeloaders should be grateful.
Actually I have been using the Aurora channel for quite a long time and Thunderbird 27a2, 28a2 and now 29a2 perform pretty well - and I have not had issues with html and compose windows for quite a while. When these versions progress to the release things should be much better for users running those later versions where indeed a number of key compose feature bugs have been fixed.
So, I am now using Thunderbird 31 and guess what?  The HTML composition is exactly as it has always been.  It changes font / state during the middle of composition if you move the pointer.  Even though this bug is "fixed".  Ha Ha Ha!  What a joke.  How old is this bug now?  8 years or more...
(In reply to Mark Banner (:standard8) from comment #259)

> If you find any issues other than bug 756984 in Thunderbird 15.0a2 or later,
> please file a new bug rather than commenting here. This will ensure your
> comments don't get lost and your issues are tracked.

Please add additional comments to bug 756984.
@KitchM
@WOLF_THUNDER

Guys, please try to be more helpful.

I for one am extremely glad that a lot of these long standing compose bugs are being addressed, even with the pain that comes along with it (the performance issues with addressing auto-fill being the most painful one for us right now).

What you may not realize is that the composer itself is the problem, and the fixes are *huge* changes to the codebase, not just minor tweaks.

By all means, add *productive* comments, especially, for example, providing reproducible test cases with precise, step by step instructions on how to reproduce the problem you are having. Yes this requires some effort on your part - but far less than what is required on the part of the developers who are working on and would really like to fix these issues.

Often these kinds of bugs only happen when you do things a certain way, and you may do things differently than the devs, which would mean they would be unable to reproduce your use case without precise, step by step instructions on how to reproduce it.

One example from my own history here at mozilla bugzilla (and I have my own past issues with flaming the devs, for which I'm truly sorry):

One bug I was experiencing had to do with new email account creation, and the dev working on it was adamant that he couldn't reproduce it.

The reason turned out to be because I was initiating the new account creation from: Tools > Account Settings > Account Actions, and he was initiating it via File > New > Mail Account.

I had even spelled out the method I was using, but he apparently just didn't even consider that *how* it (new account creation) was *initiated* mattered.

See, none of us are perfect. Yes, it was infuriating for me at the time when I learned that all of the wasted time was because he simply didn't follow my precise step by step instructions - but hopefully he learned something too...

Anyway, thanks to the devs for your hard work, and I definitely see considerable improvement in the composer, and am very much looking forward to the current regressions being fixed...
(In reply to Charles from comment #290)
> @KitchM
> @WOLF_THUNDER
> 
> Guys, please try to be more helpful.
> 

Oh, like just not mentioning the fact a bug marked solved is still persistent and has been since version 2?  That would be more helpful?

> I for one am extremely glad that a lot of these long standing compose bugs
> are being addressed, even with the pain that comes along with it (the
> performance issues with addressing auto-fill being the most painful one for
> us right now).

I have not seen the fixes to the font changing during composition....

> 
> What you may not realize is that the composer itself is the problem, and the
> fixes are *huge* changes to the codebase, not just minor tweaks.

And this fallacy and the fact the composition engine should be swapped has been known since version 2 or 3, yet it has not been replaced.

> 
> By all means, add *productive* comments, especially, for example, providing
> reproducible test cases with precise, step by step instructions on how to
> reproduce the problem you are having. Yes this requires some effort on your
> part - but far less than what is required on the part of the developers who
> are working on and would really like to fix these issues.

Reproducible like "try typing in HTML mode and then moving the caret and typing in a new spot."  That is pretty basic.

> 
> Often these kinds of bugs only happen when you do things a certain way, and
> you may do things differently than the devs, which would mean they would be
> unable to reproduce your use case without precise, step by step instructions
> on how to reproduce it.

Yes, typing and moving the caret and typing again is very hard to reproduce...


> 
> Anyway, thanks to the devs for your hard work, and I definitely see
> considerable improvement in the composer, and am very much looking forward
> to the current regressions being fixed...

Thanks for the positive spin.  And by and large I appreciate everything they do too...  but composing a message is fundamental to the way people communicate and it has been an issue from the very beginning and constantly shuffled aside, erroneously claimed resolved, new bug assignments to duck and dodge the issue, and people getting all upset when someone points out these things... etc.  

So as long as I can't compose a message with the font staying in my selected font style, I will complain, especially when it is marked "Resolved".

Thanks for the pep talk.
@WOLF

Question: do you want to actually help get your problem resolved?

This bug is a bout a very *specific* use case. Apparently that specific bug/use case has been resolved by this bug fix.

If you disagree, then please provide the *exact steps* to reproduce *your* problem, and if it is determined that your use case is exactly like the one this bug is about, and the problem is actually reproducible using the information you provide, then this bug can be re-opened.

If your problem actually turns out to be different - even if only a little - then you (or someone) can open a *new* bug to track it and get it fixed.

Does that make sense? Is that asking too much of you?
(In reply to Charles from comment #292)
> @WOLF
> 
> Question: do you want to actually help get your problem resolved?
> 
> This bug is a bout a very *specific* use case. Apparently that specific
> bug/use case has been resolved by this bug fix.
> 
> If you disagree, then please provide the *exact steps* to reproduce *your*
> problem, and if it is determined that your use case is exactly like the one
> this bug is about, and the problem is actually reproducible using the
> information you provide, then this bug can be re-opened.
> 
> If your problem actually turns out to be different - even if only a little -
> then you (or someone) can open a *new* bug to track it and get it fixed.
> 
> Does that make sense? Is that asking too much of you?

It makes sense, and it is asking too much.  See I am bitter.  I have filled bugs over the years, I have listed the steps to reproduce.  Bugs have gotten reassigned, closed, marked duplicate, and this is why we are here under this bug.  

So I will not file a new bug, when the original issue many of us have reported still remains even though it has been marked resolved, marked duplicate, filed away, promised to be fixed over and over by different devs, promised a new composition engine, and still almost a decade later is outstanding.

One example to reproduce:  Hit reply to an existing email (as long as you have "HTML" composition turned on) start typing...  then move the caret to the quoted body (or move your cursor to another window, say your web browser, or desktop or anywhere and click there), then move the cursor / caret back to the composition area where you left off and you will see the font has changed in the drop down box, before even typing again. And while it "looks" like it is the right font on screen while your happily type away (if your default font is set to the same as the composition font), it actually has changed and does not show up until the recipient gets it or you get it back when they reply again...  mid stream (where you moved the caret away and back), the font will change.  Looking like a bad glue job...

Now if your composition font is different than your default font, you would notice the change, but it would still change when the focus is moved away and then moved back.  Say you copy and paste something into the reply, you just buggered the font.

But I repeat myself... (posting how to replicate this issue)  again, and again, and again...
See bug 756984 for specific reproducible steps.
One thing I've found to be helpful
Don't attempt to place the cursor at the end of a line, but place it before the last character and re-type. Not a fix for sure, but in most cases this avoids the problem.
(In reply to Joe Sabash [:JoeS1] from comment #294)
> See bug 756984 for specific reproducible steps.
> One thing I've found to be helpful
> Don't attempt to place the cursor at the end of a line, but place it before
> the last character and re-type. Not a fix for sure, but in most cases this
> avoids the problem.

Yup, and many times I put a bunch of returns in a message at the start of just replying and a place a period and then jump back, and that seems to help most times (but not all)  But it is a pain to have to remember to do that, or not start at the end of the text when you are replying quickly and paste something in, etc.  I even highlight all the text and reselect the font I want before sending, if I remember; but again, an extra step that should not be needed.
@Charles,
This is entirely off topic, but since you started this...

>Guys, please try to be more helpful.
First off, I have been very helpful. I take my valuable time to use the product on a daily basis.  I post truthful comments.

>I for one am extremely glad that a lot of these long 
>standing compose bugs are being addressed, even with the 
>pain that comes along with it (the performance issues with 
>addressing auto-fill being the most painful one for us right 
>now).
I'm very glad that you are happy.  Please understand that many of us are not at all.  The real pain is what the users of buggy software experience.

>What you may not realize is that the composer itself is the 
>problem, and the fixes are *huge* changes to the codebase, 
>not just minor tweaks.
Anyone who knows anything whatsoever about my posts and my position on the issue will know that I have always stated that the editor (composer) needs to be replaced.  I also pointed out that the code is poorly done and documented.  I have also stated that Mozilla should have started on the rewrite long before now, and made sure that it was properly modular so that "huge" changes do not need to be done in the future.

>By all means, add *productive* comments, especially, for 
>example, providing reproducible test cases with precise, 
>step by step instructions on how to reproduce the problem 
>you are having. Yes this requires some effort on your part - 
>but far less than what is required on the part of the 
>developers who are working on and would really like to fix 
>these issues.
>
>Often these kinds of bugs only happen when you do things a 
>certain way, and you may do things differently than the 
>devs, which would mean they would be unable to reproduce 
>your use case without precise, step by step instructions on 
>how to reproduce it.
You obviously do not understand that your suggestion makes no difference and are not helpful.  Until the basic changes I mentioned above are made, the poor code will create more and more of these little problems that so annoy the user.  Going around and putting out fires wastes everyones' time and energy.  Fundamental changes need to be implemented and now.

>One example from my own history here at mozilla bugzilla 
>(and I have my own past issues with flaming the devs, for 
>which I'm truly sorry):
>
>One bug I was experiencing had to do with new email account 
>creation, and the dev working on it was adamant that he 
>couldn't reproduce it.
>
>The reason turned out to be because I was initiating the new 
>account creation from: Tools > Account Settings > Account 
>Actions, and he was initiating it via File > New > Mail 
>Account.
>
>I had even spelled out the method I was using, but he 
>apparently just didn't even consider that *how* it (new 
>account creation) was *initiated* mattered.
All your explanation does is demonstrate how little the programmers understand their own code.  Why multiple ways of doing things should use separate processes is bizarre.  Why in the world would someone duplicate the process by doing it differently?  Good programmers pick the best way and stick with it.

And, yes, we've all worked with this kind of narrow-minded person many times.

Rgarding the rest of what you wrote:
There is no excuse for poor code or ignorance in customer relations.  Period.  It should not be allowed and it should not be excused.

Bad decisions on the part of Mozilla are what is causing the problem.  And provably so.

Please don't forget that it appears that 98% is as good as it gets for these programmers.  Sadly, that isn't a fix.  Posting something like that as fixed is disengenous.
(In reply to KitchM from comment #296)
> Anyone who knows anything whatsoever about my posts and my position on the
> issue will know that I have always stated that the editor (composer) needs
> to be replaced.

Everyone I know, especially the Thunderbird devs themselves, have known this far longer than you or I have, but saying or knowing something needs to be fixed, and doing the work, are two very different things.

> I also pointed out that the code is poorly done and documented.

So how many patches did you provide to fix it?

> I have also stated that Mozilla should have started on the
> rewrite long before now, and made sure that it was properly modular so that
> "huge" changes do not need to be done in the future.

I'm curious as to how many dozens of development hours you offered to contribute (or sponsor) to get it done?

Seriously... this is free software, and maybe you are unaware that there are, and have always been, far, far fewer developer resources dedicated to Thunderbird development than were ever dedicated to Firefox?

Thunderbird is, and has always been the red-headed step-child, and it got much worse when Mozilla partially abandoned it.

RKent and others are valiantly trying to put together some kind of structure that will allow Thunderbird to not only survive, but to thrive.

Bottom line, if you aren't prepared to put your money where your mouth is, or at least try to stay positive/productive, everyone would be better off if you just kept your insultingly derogatory comments to yourself.
Well, if you're really that bitter, then no offense, but it would be better for Thunderbird and everyone all around if you just stopped posting here, rather than venting, which accomplishes nothing productive, and in fact may even be *counter*-productive (as any devs who might be thinking about contributing may not want to be subjected to such obnoxious attacks.
(In reply to Charles from comment #298)
> Well, if you're really that bitter, then no offense, but it would be better
> for Thunderbird and everyone all around if you just stopped posting here,
> rather than venting, which accomplishes nothing productive, and in fact may
> even be *counter*-productive (as any devs who might be thinking about
> contributing may not want to be subjected to such obnoxious attacks.

After a decade of broken promises, reshuffling of tickets, claims to be fixed, etc, I think it is fair to be bitter.  It is not like it is a trivial thing, it is core to the act of composing a reply....  So I shall vent.  But I have not "attacked" anyone.  I have just pointed out the facts of the matter that is keeps getting pushed of, "resolved" and promised of "will be in version 15", "will be in version 28" stories that never come to fruition.

If devs want to use that flimsy excuse of someone pointing out the historical lies and bug shuffling as a reason to let it sit uncorrected, so be it.  Lame...
I propose that everyone ask themselves *before* posting, "Will this help?"
(In reply to Vladimir G. Ivanovic from comment #300)
> I propose that everyone ask themselves *before* posting, "Will this help?"

Agree 1,000%.  

"Coming in version 15" when it really isn't does not help.
"Ethan is working on it" when he isn't, does not help.
"Resolved", when it isn't, does not help.
"Devs might not take it up if you point out the lies", does not help.

Stirring the pot now and again at least keeps some people aware that the issue remains, so it helps...  I mean, it has only been 10 years, what is the rush, right?
Please post only relevant helpful information. 
If you can add helpful information like which OS, version of Thunderbird, specific information, helpful workarounds then please offer the info. 
If this still effects you please state eg: 'still a problem in version 31.2 on OS windows 8'
I'm following this bug and do not wish to receive dozens of useless spamming with unhelpful verbose derogatory 'chat'.
Since this bug is closed, I have captured the necessary information into bug 756984.

It is true that the composition font is lost in some cases and the default font is used instead.
This only goes unnoticed, if in your setup the these two fonts are identical. In this case the message gets sent with incorrect/missing font information.

One workaround is to not have the default font and the composition font identical, then at least the problem can be recognised and fixed before sending the message. Not ideal, but workable.
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: