Closed Bug 514265 Opened 15 years ago Closed 13 years ago

email font changes from default font to width variable

Categories

(Thunderbird :: Message Compose Window, defect)

Product:
Thunderbird
Component:
Message Compose Window
Platform:
x86
Windows Vista
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

Status:
RESOLVED DUPLICATE of bug 250539

People

(Reporter: jerry.pollio, Unassigned)

References

(
URL
)

Details

(Whiteboard: [gs])

Attachments

(1 file)

Ambiguous cursor position
2.34 KB, image/gif
Details 
User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 6.0; en-GB; rv:1.9.1.2) Gecko/20090729 Firefox/3.5.2 GTB5 (.NET CLR 3.5.30729)
Build Identifier: mozilla beta 3

many times while typing my default font changes to variable width without me doing anything. This happens again and again so I manually change the font back to the default

Reproducible: Always

Steps to Reproduce:
1. iam typing in my default font
2.then w/out any thing clicked or moved the font defaults to variable width
3.i manually set it back to the default
Actual Results:  
as mentioned above the font changes without doing anything

Expected Results:  
i manually correct the issue

maintain the default font
Jerry next time it happens can you have a look into Tools -> error console  and see if something looks suspicious there ?

I don't have this behavior :
   Do you have extensions installed - if you disable them (using the safemode [1]), can you still reproduce the issue ?
   Does the text you need to type need to be a certain length before the issue is visible ?

[1] http://kb.mozillazine.org/Safe_mode
Component: General → Message Compose Window
QA Contact: general → message-compose
Version: unspecified → 3.0
Reporter could be a dupe of bug #248377?
Or probably it is a dupe of bug #250539?

What you think about comment #1 and comment #2?
Same problem for me.

Version : Mozilla/5.0 (Windows; U; Windows NT 5.1; fr; rv:1.9.1.5) Gecko/20091204 Lightning/1.0b2pre Thunderbird/3.0
This behaviour was in Thunderbird 2 also.

1. set a default font in the option windows
2. write a new mail with a signature
3. click on the signature
4. click on the beginning of your message, font has been changed to "variable"

OR

2. reply to a mail
3. click on the included message
4. click on the beginning of your message, font has been changed to "variable"
I can reproduce it too even more easily.

Mozilla/5.0 (Windows; U; Windows NT 5.1; es-ES; rv:1.9.1.7) Gecko/20100111 Lightning/1.0b1 Thunderbird/3.0.1

1. Set default font to Calibri (for instance)
2. Begin writing message. For now, everything is OK
3. Click on "enumerated list" or in "bullet list": font changes to "variable"

The change is not apparent when redacting the message because I set "variable" = "Calibri", but when my colleagues (who don't have these settings) receive the message, they can see the difference.
Whiteboard: dupme
Exactly the same here - default font calibri (others is same problem): 

Write text in calibri - select bullets - font changed to varible
Insert link, afterwards all new text is written in varible

VERY annoing - this bug was also present in TB2
The bulleted list problem is definitely bug 250539
This bug is about fonts changing "as you type"
For that case we don't yet have clear steps to reproduce the issue.
I think the whole problem here might just be that the cursor could be showing
an incorrect position from where it actually is.
Using the steps in comment 4 above, but trying to return focus to the end of
a previously typed line, it was very easy to have the cursor positioned just
after the last character, yet actually outside of the font tag.

Confirming.
One thing that might fix this kind of problem would be to have p, font tags etc.
temporarily visible in the composition, to aid in cursor positioning.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Here is a screen snippet with the cursor position adjacent to the last typed
character, but actually outside of the message composition Font tag
Comment 4 - its a mixup where the signature is changing BUT i have the same problem using calibri in both the text area and the signature are, thus clicking  the curson in signature and back still change the font to varible witdh

(In reply to comment #8)
> I think the whole problem here might just be that the cursor could be showing
> an incorrect position from where it actually is.
> Using the steps in comment 4 above, but trying to return focus to the end of
> a previously typed line, it was very easy to have the cursor positioned just
> after the last character, yet actually outside of the font tag.
> 
> Confirming.
> One thing that might fix this kind of problem would be to have p, font tags
> etc.
> temporarily visible in the composition, to aid in cursor positioning.
Dear Joe 

I have 3 computer, 2 pce. with TB3 and 1 pce. with TB2 - all of them (with or without signature is easy to recreate: write an intro text on a new mail - mark the last word, and add a link target - aften the link is written, choose ok in the dialog, back in editor - continue in the same line with more text. 
Now you will ses that the text AFTER the link pating is in varible width. 

Another try: paste a link fra Firefox, and type text after this link, same problem. 

The above 2 is possible on all three computers with TB
Hope this can help reproduce ?   
(In reply to comment #7)
> The bulleted list problem is definitely bug 250539
> This bug is about fonts changing "as you type"
> For that case we don't yet have clear steps to reproduce the issue.
This is a REALLY anying bug, and other user in DK are leaving TB because of this. 
When will there be a fix, couldn't be that difficult ?
I have Letter Gothic Std 16 set as the default font under "Formatting" under "Display". In the "Advanced" subpane, I have Serif, Sans-Serif, and Monospace all set to Letter Gothic Std 16. "Allow messages to use other fonts" is UNchecked. And yet TB insists on using Arial or Helvetica or something else. I select all and change the font to fixed width, which puts all my text in Letter Gothic Std 16, but as soon as I start a new sentence it's back to Arial. VERY ANNOYING and should have been _FIXED_ in TB3, not made worse.

Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-GB; rv:1.9.1.8) Gecko/20100227 Thunderbird/3.0.3
This is terribly frustrating and happened with 2 also. (Now using 3.0.3)

Typing quickly seems to make it happen. If I back up and start at the last "good" letter, ie in the font I want, and type slowly, it usually is okay. Please fix this. It's kind of hateful. :(
I type with one finger only and still it happens.  It doesn't happen on a regular basis, which will make it quite hard to detect and fix its cause.  The way I get around it, I type a "good" letter and then I get behind it typing the message at hand.  When I am done, I erase the extra letter.  Whatever text with different fonts may be below my response/forward might have something to do with it.
If it can help, here is a simple way to reproduce it systematically (at least with me) : with prefs settings to some font (e.g. Verdana),
1. Select a incoming mail
2. Click the "Reply" Button
3. Start typing some words
4. move the cursor back, with, let's say, Ctrl+left arrow
5. Bring the cursor back to the end of the line with the "End" key (on keyboard)

it always lead to the loss of the selected font.
I can add an additional wrinkle to what I believe is the same problem.  I have the same issue as described above (font switches to TNR from my own default, Comic Sans Serif, randomly while I type) but remarkably, this change only shows up in the recipient's mail reader!  It all displays as Comic in my composition window.  When the recipient replies, including my original message, I can see two fonts.  Here is an HTML snippet from a reply I got (to a message I sent earlier today) that exhibits this behavior:

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
  <meta content="text/html; charset=ISO-8859-1"
 http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">

<font face="Comic Sans MS">Hi, Karen.&nbsp; Thanks for re-sending.&nbsp; ... (various junk elided) ... not in the March break.</font>&nbsp; I'll bring this up at our next executive meeting.<br>
<br>
Patrick<br>
<br>


The last sentence ("I'll bring this up at our next executive meeting.") shows up in TNR; the rest in Comic.  The original message all appeared in Comic in my composition window, but I've confirmed with the recipient that by the time she got it the last sentence was in TNR.  I tend to navigate by keyboard rather than mouse so it's entirely possible I used the End key at some point, although I've since tried to reproduce this with emails to myself and failed to.
This happens to me nearly every time I reply to an email.  See Comment #19.  That seems to re-create the problem every time.
I have exactly the same experience as Lydia (#17), with my text changing from the specified Times to Variable Width. It would happen occasionally under Tb2, usually when I came out of italics quickly. With Tb3 it happens with almost every email I compose (reply or new) unless I type very slowly. I don't actually have to do anything (except type) to cause it to happen.
(It also changes size from the specified Large to Medium, but I've given up on that and now compose in Medium, wearing my reading glasses; that's not the best solution!)
I've tried raising this on forums.mozillazine.org, and other users report the same problem there, but the usual gurus haven't met the problem and have no suggestions to fix it. Several people have stopped using Tb because this bug is so frustrating; I may follow them, because it's driving me mad.
Could someone please look into this, find out what's causing it, and fix it? As I say, Tb3 has made it immeasurably worse.
Possible dup of bug 536613 and others mentioned previously.  THIS IS A HUGE ISSUE.
to: comment #24 - Correct it is HUGE and VERY ANNOYING. The impact error rate is 100% if you have choosen another font.
Since this bug is VERY old, and nothing happens, I have given up on Thunderbird, and reinstalled MS Outlook. I am awaiting a bugfix before considering changing back. 
HOPEFULLY Mozilla soon open there eyes for this bug :-)
Is this an HTML problem only? I seldom compose with HTML and don't have this issue with TB 3.1.2 on a G4 with OS X 10.5.8.

However, I did have a difficult to track down font issue with an identical G4. I eventually discovered that most of the considerable fonts in /Applications/Thunderbird.app/Contents/MacOS/greprefs/all.js were set to zero size. I removed many unwanted fonts and set all the others to reasonable sizes. This cured my problems with this G4.

The other identical G4 has not had the problem - on checking I see that all its font sizes in greprefs are reasonable. Although the G4s are identical their TB update histories may be different ie fresh installs vs updates may have varied from time to time.
Although I have associated the GS topic shown in the "URL:" field with this bug report (and vice-versa), I only did it because Bug 536613 was DUP'd to this bug.  It was not my conclusion that the problems described are related.
URL: http://gsfn.us/t/15jkn
Whiteboard: dupme → [gs] dupme
I question if 536613 really is a dup to this one.  536613 included font SIZE decreasing suddenly as you type a reply or new message.  This bug, however, seems to focus on the TYPE of font changing.  The sudden change of TYPE and SIZE may be related (don't know), but this bug--now that the other is dup'ed away--does not fully cover both of the issues: TYPE changing and SIZE changing.
Un-DUPing 536613 w/concurrence from :Usul.
Can the original reporter confirm that the Steps to Reproduce are accurate; that is, it is only necessary to type the text and NOT reposition the cursor at all ?  If cursor positioning is involved, please check to see if the problem is that described in Bug 273622.
Here is, for me, a guaranteed reproducible way to see the font size reduction bug:

1. In Tools>Options>Composition, in HTML section, set Calibri font, size LARGE.
2. Open a message previously received.
3. Click reply.
4. Type a word.
5. Press right arrow, left arrow (you are back at the end of the typed word)
6. Type anything; it will be in the reduced font.

I do not know if any other settings in options affect (allow/prevent) this manifestation.
Additional to previous... 

I have found if I click ANYWHERE in the reply window, then back at the point of typing, continued typing will be in the reduced size.  I cannot assert it is a certainty, but it appears that a cursor repositioning is at least one of the causes for this bug to present itself.
Nope.  I don't even have to do that.  I can just be typing, and the fount will change from Times to "Variable Width", and if I'm in Large, it will change to Medium. It was an occasional problem under Tb2; with Tb3 it happens with nearly every email I write.  It's quite unacceptable.  I'm just glad that other people are at last waking up to realising that this is a MAJOR problem that must be sorted out.
(In reply to comment #32)
> Additional to previous... 
> 
> I have found if I click ANYWHERE in the reply window, then back at the point of
> typing, continued typing will be in the reduced size.  I cannot assert it is a
> certainty, but it appears that a cursor repositioning is at least one of the
> causes for this bug to present itself.

Please see core bug 588347
(In reply to comment #31)
(In reply to comment #32)
These are examples of the cursor-positioning bug described in Bug 273622 and in
one of the comments in Bug 250539.  To explain:

When you compose a message in HTML, the message starts out (from what I
understand in reading the 93rd comment in bug 250539) with your desired font
specified as:
<font...>[CursorHere]</font>

While you don't see these tags, they're there; the cursor is positioned between
the opening and closing tags.  When you type, the text is in the desired font. 
When you click back to the point of insertion (or use the cursor arrow to move
past the tag), the cursor is positioned OUTSIDE those tags, so the font changes
to (I think) the system-wide font default.

(In reply to comment #33)
> Nope.  I don't even have to do that.  I can just be typing, [...]

Being able to reliably reproduce the problem is important.  As I've noted
elsewhere (GSfn and other bugs), please try to consider what may be causing the
change to occur (for example, the reporter of Bug 569165 believes AutoSave may
be a factor).  When you notice the problem, think back to what you did just
before that, or what could have happened "in the background" that may have
caused it (e.g., Periodic message check, alert from another application, etc.).
 Until the problem can be reliably reproduced, the defective code cannot be
identified -- or fixed.
This happens to me all the time, it never happens in Apple Mail or Entourage or any other mail client ONLY Thunderbird.  As others have said, start to type a reply simply stop and wiat a moment and then continue typing and the font has changed to smaller ro to different or something else font.  Instaed of Body Text Arial it becomes "variable width" and smaller size.  Certainly this is easy to reproduce by clicking elsewhere and then resuming typing, but it also happens almost all the time by just stopping for a minute and then resuming typing.  It is the most annoying thing going.
(In reply to comment #36)
> [...] As others have said, start to type a reply simply stop and wiat a moment  
> and then continue typing and the font has changed to smaller ro to different  
> or something else font.  [...] but it also happens almost all the time by just 
> stopping for a minute and then resuming typing.  

I tried that while I was responding to a topic in "Get Satisfaction"; see the second and third paragraph of this reply:
http://getsatisfaction.com/mozilla_messaging/topics/cha_cha_changes#reply_3243129

If you can reproduce this problem, at will, by just sitting there and waiting for the font setting to change, then please try to determine what (external event) is making it change, as requested in Comment #35; I tried exactly those steps (type and wait, type and wait) and the font did NOT change from my default.

The original problem reporter has agreed that his problems are most likely always due to the cursor-positioning bug:
> Your additional explanations (<font...>[CursorHere]</font>), have convinced 
> me that cursor positioning is actually behind my bug [...] I haven't found any 
> other way to reproduce it, like in the middle of typing my text while answering 
> or replying to a message.

Since others believe that there ARE cases where the font/size will change for reasons OTHER than the cursor-positioning bug, I will not DUP this bug report yet -- but repeatable "steps to reproduce" are needed sometime in the next couple of months so this can move toward a resolution; otherwise, leaving this bug open does not help this, or any other, problem get fixed.
I don't normally compose with HTML but I decided to have a look at this bug. Here are a few thoughts.

I have not had random font changes but the font does change when typing forces a new line above a signature. It is not easy testing with signature turned on. It is difficult to tell if one is getting too close to the signature area and it is surprising that a forced new line does not move the sensitive area down although it clearly moves the signature. Also once having got 'contaminated' by the signature TB does not to revert to the correct font when typing is moved elsewhere.

I am surprised to discover that TB attempts to detect local tags (not sure if it detects local css) and match the adjacent font. It does this without displaying the settings it has detected, unlike many editors - I think this is ergonomically wrong. I had expected my selected font to be used until I changed it - ie I expect my tags to be placed wherever I start typing. If TB developers wish to continue with this mode of operation it would be helpful if they could make the displayed font settings match the font being used and provide an override so that users can enforce their settings.

Perhaps future reports should say if a signature is turned on and if typing is getting close to the message being replied to.
Answering previous post questions, I =do not= have signature turned on, and my "contact" with the bug occurs when typing replies or forwards--thus the material below the typing point is the quoted original message.  The quoted original message below the type point generally shows up in the medium font size, while I am typing my reply above it in large size--until Thunderbird changes it to the medium font.

Also "Change quote and reply format" extension, which creates an Outlook-like identification header for the quoted email, is operating.

I do not know if this bug appears when typing a new message as I do few of those.
Sorry for the multiple posts, but I keep finding new info, and I hope this will help someone identify the cause and the fix...

If I open a Reply, and the first keystroke is a right-arrow, the font shown in the info line changes from Calibri to Variable-Width and you will be typing in the medium font size rather than the large it should be, even if you left-arrow or up-arrow back to the 1st line 1st character position.

I don't understand why Tbird code thinks I want to change font when I have returned to the first character position.  It did not used to do this in earlier versions.
In reply to comment 35:
   >(In reply to comment #33)
   >> Nope.  I don't even have to do that.  I can just be typing, [...]
   >Being able to reliably reproduce the problem is important.

Okay. Fair enough. I think comment 38 may have pinpointed the cause.  Tb is picking up on whatever other founts are in an email, and ignoring whatever you've set in Tools>Options>Composition>Fount. 
 
Most of my new emails have a sig which is supposed to be in Times, but since Tb3 has become Variable Width (why? who knows...).  Even if I delete the sig at any point in composing a new email, the last character point in the email "remembers" Variable Width, and at some point while typing my new text switches to that.  The same applies if I'm replying to an email, leaving the original sender's text below mine: at some point while I'm typing it switches fount -- because above the previous text is the line "On 20/08/2010 00:37, XXX YYY wrote:" and this line is in variable width.  And if I compose a new email in an account where I don't use a sig, I don't get the problem.

But here's weird. Even if I Ctrl-A and turn all the text (including the sig or the previous email) to Times, which you might think should fix the problem -- it doesn't.  I'm typing away, and between one word and the next my text switches from Times to Variable Width.
Michael

I think the issues need separating - perhaps into:

1 - Signature enabled in Account Settings - deleting it per email is not the same as disabling

2 - Compose style altering extensions enabled - I think tests should be done with these disabled

3 - Cursor movement by mouse or arrows etc

4 - Apparently totally random

In relation to 4 it might be useful to know if typing had just forced a new line or if auto-save had activated - on my Mac the modified time of files in Drafts lag slightly so it is not easy to see the save time until a while later.

TB version and OS might be useful - mine are TB 3.1.2 / OS X
(In reply to comment #42)
> I think the issues need separating - perhaps into:
> [...]
> 4 - Apparently totally random

This is the "description" in this bug report, and the case for which I am seeking repeatable "Steps to Reproduce" (since the original reporter has agreed that this bug report was an attempt to describe/report the problem described in Bug 273622).   All other "issues" would be the subject of other bug reports -- which can certainly be filed, if necessary.  

The operable word in Neville's comment above is "apparently"; it does not matter whether the STR involve signatures or not (I'll accept them either way); following the STR, the problem MUST be repeatable in "Safe Mode" (or clearly identified to be a toolbar setting that is causing the bad behavior -- i.e., no extensions); and the problem must not be one of the cursor-movement cases as described the 93rd comment of Bug 250539 and the description in Bug 273622 (or a variation thereof -- i.e., ANY case of positioning the cursor "outside the outmost font element").
This is a bug affecting so many people, I felt it appropriate to post this workaround I finally created to avoid the APPEARANCE of the font change.

My method that avoids the appearance of font change on cursor move (works for me anyway).  It all depends on font selections.

In Tools>Options>Display>Formatting>Advanced...

reading from the top down:
Western
Proportional: Sans Serif   18
Serif: Bitstream Vera Serif
Sans-serif: Bitstream Vera Sans (critical: this one will automatically become the default font)
Monospace: Bitstream Vera Sans Mono  18
Allow messages to use other fonts - checked

In Tools>Options>Composition>General>HTML Font...

Bitstream Vera Sans  (medium)
This one must match the Sans-serif selection in the Display settings above.
(I chose the Bitstream font because it seemed to be one of the largest at "medium" setting, and I prefer a slightly large font)

The result of these settings is that the "Variable Width" font is the same font as your "starting" font.  As a result, a cursor move DOES change from the selected font to "Variable Width," but they are the same font--so there is no change in appearance.
(In reply to comment #45)
> This is a bug affecting so many people, I felt it appropriate to post this
> workaround I finally created to avoid the APPEARANCE of the font change.
>
With all due respect to the work you have put into achieving this "workaround", this is not in any way a solution to the problem; it's going a complicated way around in order to capitulate completely to the problem.

I'm very glad that the Powers-That-Be are at last beginning to think about the possibility of perhaps accepting that there just might be a problem; that's the first (long-overdue) step towards looking for ways to solve it.  I live in hope...
I didn't say it was a solution--I said it was a workaround.  

Believe it or not, some people might want to use Thunderbird without the font change due to cursor move aggravation during the period before a true "solution" is put into the product.  As we well know, there has been no rush by the powers that be to do that up to this point.  Thus, who knows how long before the real fix happens.  In the meantime, I will use the workaround.  You don't have to if you don't want to.
(In reply to comment #47)
> I didn't say it was a solution--I said it was a workaround.  
> 
> Believe it or not, some people might want to use Thunderbird without the font
> change due to cursor move aggravation during the period before a true
> "solution" is put into the product.  As we well know, there has been no rush by
> the powers that be to do that up to this point.  Thus, who knows how long
> before the real fix happens.  In the meantime, I will use the workaround.  You
> don't have to if you don't want to.

Very well; point taken.
Here's a simpler workaround, which allows you to have the fount you actually want to use -- in my case a serif fount, Times, rather than the sans-serif fount forced on you by Tb:
Type your email, and when Tb changes your fount arbitrarily, ignore this distraction and carry on typing.  When you've finished, hit Ctrl-A, select the fount you actually want, make sure you've got it, then hit Send before Tb changes its mind.
This problem drives our office crazy. To the point where people are changing back to Outlook....
QuoteAndComposeManager extension add-on

From elsewhere, I read "...I turned on the setting "Stabilise predefined font in replies and forwards" in the "Font" tab. It seems to have solved to problem also for new messages."

QuoteAndComposeManager does alleviate the problem considerably...first some description: the fundamental problem is a hidden [/font] tag in the compose window (read elsewhere in this thread to get the details).

What this QuoteAndComposeManager extension add-on seems to do is, when you move the cursor away from the line you were typing on and then come back to the same place, with this, the cursor has been placed back INSIDE the hidden [/font] tag. Thus, your typing, both on your compose screen and on the recipients screen, continues with the same font you had specified for compose.

Without this extension installed, when you clicked the cursor back to the previous typing point, or moved it back with arrows, it was OUTSIDE the [/font] tag--and the font changed to whatever was the Variable Width font.

So this DOES improve the situation. BE AWARE that the next line down though =IS= Variable Width, so if you jump down any lines by any means other than using enter, the font spec will change.
A simple solution could be to integrate Stationary plugin inside Thunderbird. For the moment it is is the only solution able to solve the problem.
Default composing font in option should be removed because it does not work.
When Thunderbird composer will be corrected|refactored|replaced|rebuild, then Stationary could be removed.

As everyone, I'm very disappointed with this bug, any new development should be stop until this one is solved !
I believe that last version of QuoteAndComposeManager (v. 0.3.17 or higher) has an effective fix for this annoying problem.
NEW VERSION of add-on extension QuoteAndComposeManager v. 0.3.17 for Thunderbird as of November 2010...   DOES essentially make the font-change-on-cursor-move problem go away on both the composer's end and the recipient's end. It gives you consistent font even with cursor moves!  Hurray!  I believe the bug has been defeated.  

It is available here 
http://nic-nac-project.org/~kaosmos/realborders-en.html

This works. I am using it without issue. After installing, you MUST checkmark the item "Stabilize predefined font" in the Font tab in the extension's Options. 

In addition, this version now lets you define the font size you and receiver sees in pixels rather than "small/medium/large" or in "points."  That is very nice too.

It is also compatible with the "Change quote and reply format" extension that gives you Outlook-style message headers for replies/forwards.
#53

Im sorry but your extension DOSENT do the job.

Test is by:
1: type with your own predefined font
2: paste some text from another program 
3: write after the pasted text. 

The result is that the text written after the pasted text, if formatted just like the pasted text, and not as expected formatted like set in your own preferences 

VERY annoying and cannot understand why Mozilla dosent want this to be corrected.
I don't know what happened in your case but I just started a reply, enter down two lines, pasted in some text from elsewhere, enter twice, type some more--it was all in the same font as I had selected.

The pasted-in text (unless you bring it in with html formatting already embedded in it--did yours?) should be in YOUR font, not the font of the pasted text. I strongly suspect this is what happened because you say, "...the text written after the pasted text, if formatted just like the pasted text..." 

If you bring in text that itself changes the font, then what you said ie exactly what would happen because the pasted-in text itself changed the font. Everything after it would continue in that font--as it did in your case.

There are also other settings in Tbird that MIGHT interfere with this (for example, a given address set to always receive a certain format)--and others.
in reply (In reply to comment #54)
> #53
> 
> Im sorry but your extension DOSENT do the job.
> 
> Test is by:
> 1: type with your own predefined font
> 2: paste some text from another program 
> 3: write after the pasted text. 
> 
> The result is that the text written after the pasted text, if formatted just
> like the pasted text, and not as expected formatted like set in your own
> preferences 
> 
> VERY annoying and cannot understand why Mozilla dosent want this to be
> corrected.

About my extension, I can reproduce this problem and I hope to be able to fix also this one in next version.
Many posting here would have a better understanding if they were to occasionally examine the source code of their messages.

As far as I know this cannot be done with Thunderbird until messages have been sent. I simply send a test message to myself. There is no need to wait for the message to be delivered as the copy in the Sent folder will have HTML source code.
(In reply to comment #57)
Stationnary addon extension adds a tab menu which enable you to switch between HTML source and regular edit windows.
You can also modify HTML source !
Thanks caron.

I Have just tried it and unfortunately the Stationary extension causes Thunderbird 3.1.6 to freeze on my G4 with OS X 10.5.8. This is repeatable and is only resolved by force quitting Thunderbird. During the freeze my 'idle' Thunderbird switches between 20% and 40% CPU activity.

https://addons.mozilla.org/en-US/thunderbird/addon/4394/reviews/255738/
(In reply to comment #59)
Sorry Neville for the bug you encountered, I whish your bug will be quickly solved by Arivald.

For others, just take the time to configure and understand Stationary, and it will truly solve your Thunderbird experience. 
It is for me the only workaround with this bug !
I don't know why people are still talking about problems with Stationery, when QuoteAndComposeManager v. 0.3.17 works so well.  Find it at http://nic-nac-project.org/~kaosmos/realborders-en.html.  Install.  Then all you need do is check "Stabilize predefined font" in its options, and the problem that was too scary for Tb's writers even to dare look at is solved.  End of.

Thank you Paolo (Kaosmos)!
Ok.. here are some additional informations.
I use dual boot, Windows 7 when i work in AutoCad and Linux Mint when not working in autocad.

1:First i installed it on the linux Mint, and nothing happend, thats why i posted comment 54.

2:After that i installed in Windows antd the extension works very after setting it up IN WINDOWS 7 version of Thunderbird.

3: Back to Linux, re-instaleld and setup the extension, and now it works. 
I am not sure why it dident work the first time.

Hope this is enough information for others to make it works. 

AND --- I AM ONE HAPPY USER lets spred the word
Thanks a million, for my boss and thus for me it seems to be life saver.
Whiteboard: [gs] dupme → [gs]
Do we think this is a Core problem?  If yes, can somebody please provide STRs which do not rely on Thunderbird?  This bug is currently too confusing...
(In reply to Ehsan Akhgari [:ehsan] from comment #64)
> Do we think this is a Core problem?  If yes, can somebody please provide
> STRs which do not rely on Thunderbird?  This bug is currently too
> confusing...

Selection problem here:https://bugzilla.mozilla.org/show_bug.cgi?id=588347#c4
is at least a contributing factor.
(In reply to Joe Sabash from comment #65)
> (In reply to Ehsan Akhgari [:ehsan] from comment #64)
> > Do we think this is a Core problem?  If yes, can somebody please provide
> > STRs which do not rely on Thunderbird?  This bug is currently too
> > confusing...
> 
> Selection problem here:https://bugzilla.mozilla.org/show_bug.cgi?id=588347#c4
> is at least a contributing factor.

That's a dupe of bug 250539.  If there are no other problems here, this can be duped against that bug as well.
It seems like this has the same underlying cause as bug 250539, except in this case, the signature wrapped in the pre tag is inserted before the bulleted list. But this is the html we get when I do the steps that recreate this bug:

<font size="-1">new</font> new<br>
<pre class="moz-signature" cols="172">-- 
plain text signature</pre>


The steps are simple.

Setup a plain text signature for your account in account settings
write an e-mail for that account
type a letter at the start of the e-mail message
click to the subject line
click back after the e-mail message and type something else. The font will change from small to medium for the new text.

Ehsan, if it still sounds to you like the bugs are the same, let me know and I'll mark it as a dup.
(In reply to David :Bienvenu from comment #67)
> It seems like this has the same underlying cause as bug 250539, except in
> this case, the signature wrapped in the pre tag is inserted before the
> bulleted list. But this is the html we get when I do the steps that recreate
> this bug:
> 
> <font size="-1">new</font> new<br>
> <pre class="moz-signature" cols="172">-- 
> plain text signature</pre>
> 
> 
> The steps are simple.
> 
> Setup a plain text signature for your account in account settings
> write an e-mail for that account
> type a letter at the start of the e-mail message
> click to the subject line
> click back after the e-mail message and type something else. The font will
> change from small to medium for the new text.
> 
> Ehsan, if it still sounds to you like the bugs are the same, let me know and
> I'll mark it as a dup.

Can you please make the STR a bit more precise by saying where you click and type in the DOM, and also provide a sample of the before/after HTML document?
Before you type anything (but after the signature is inserted, obviously) this is what is in the editor.
<br>
<pre class="moz-signature" cols="172">-- 
plain text signature</pre>

Then, click at position 0 (top left corner of the compose) and type anything (e.g., "new")

Then you get this:

<font size="-1">test</font><br>
<pre class="moz-signature" cols="172">-- 
plain text signature</pre>

Then, click after the "new" and type again. Then you get the html I previously pasted:

> <font size="-1">new</font> new<br>
> <pre class="moz-signature" cols="172">-- 
> plain text signature</pre>

Hope that helps...it's trivial to reproduce in Thunderbird with a plain text sig and a non-default font selected.
Oh, duh, I forgot to say that you need to change your default composition font to something like "small" in preferences, composition. And if it's not clear, the > at the beginnings of the lines in the final html are because I pasted from quoted bugzilla text - ignore those.
Yes, in that case, this is a dupe of bug 250539.
Status: NEW → RESOLVED
Closed: 13 years ago
Resolution: --- → DUPLICATE
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: