203810 - font style in prepopulated text in a reply "xyz wrote:" (attribution line) doesn't follow settings; causes replied text to not be default in cases

Status: RESOLVED WORKSFORME

(MailNews Core :: Composition, defect)

Description

[esther]

Using trunk builds 20030428 onw winxp, macosx and linux if the user changes
their Mail composition default for font style, the prepopulated text used in 
Replys "xyx wrote:" does not change to this default.  If the user backspaces in
the first line all the way to the left, the newly typed text picks up the font
style of this pre populated text.  

1. Launch app - set to reply above quoted text (default for commercial builds)
2. Change your mailnews preference for composition to another font style.
3. Click Reply to a message someone sent preferably with the default font style.
4. Start typing (note you will see your default style), backspace all the way 
to the left margin, start typing again.

Result: the font is now of the style of the prepopulated text instead of your
default text.

Expected:  to be able to backspace and still have my default font used.

Comment 1

[esther]

nomintaing because this is a new feature and mistakenly backspacing in a reply
can look as though this feature doesn't work all the time.

Comment 2

[esther]

Also happens when Forwarding Inline, the prepopulated hearder of the forwarded
message has the same affect at the prepopulated text in a reply.

Comment 3

[(not reading, please use [e-mail] instead)]

over to shuehan

Comment 4

[Samir Gehani]

adt: nsbeta1-

Comment 5

[Mike Cowperthwaite]

*** Bug 251364 has been marked as a duplicate of this bug. ***

Comment 6

[Mike Cowperthwaite]

*** Bug 245581 has been marked as a duplicate of this bug. ***

Comment 7

[Mike Cowperthwaite]

See (from the dupe) bug 245581 comment 1.

Comment 8

[Mike Cowperthwaite]

*** Bug 273622 has been marked as a duplicate of this bug. ***

Comment 9

[Mike Cowperthwaite]

*** Bug 287013 has been marked as a duplicate of this bug. ***

Comment 10

[Mike Cowperthwaite]

*** Bug 353424 has been marked as a duplicate of this bug. ***

Comment 12

[Rob Hasselbaum]

Attachment: Use HTML font preference for reply and forward headers

With this patch, Thunderbird uses the user's preferred HTML font face/size for reply and forward header text. I added logic in nsMsgCompose and the MIME routines to wrap header text in font markup if we are in HTML composition mode and a non-default font face or size was chosen in preferences.

Comment 13

[Rob Hasselbaum]

Attachment: Updated patch that addresses TT special case

Upon further testing, I discovered that the "Fixed Width" meta-font requires use of the TT tag instead of FONT. Updated the patch to address this special case.

Comment 14

[Scott MacGregor]

Comment on attachment 260269 [details] [diff] [review]
Updated patch that addresses TT special case

some minor nits:

+ nsXPIDLString font_face;

font_face should be a nsString

This:

+      if(NS_LITERAL_STRING("tt").Equals(font_face))

should be
font_face.EqualsLiteral("tt")

and does it need to be a case insensitive compare?

Can this:

aText.Append(NS_LITERAL_STRING("</TT>"));  

be aText.AppendLiteral(...)?

Use a nsString here:
+ nsXPIDLString font_size;

could this be a simple switch statement?

+      if(NS_LITERAL_STRING("x-small").Equals(font_size))
+        font_size.Assign(NS_LITERAL_STRING("-2"));
+      else if(NS_LITERAL_STRING("small").Equals(font_size))
+        font_size.Assign(NS_LITERAL_STRING("-1"));
+      else if(NS_LITERAL_STRING("large").Equals(font_size))
+        font_size.Assign(NS_LITERAL_STRING("+1"));
+      else if(NS_LITERAL_STRING("x-large").Equals(font_size))
+        font_size.Assign(NS_LITERAL_STRING("+2"));
+      else if(NS_LITERAL_STRING("xx-large").Equals(font_size))
+        font_size.Assign(NS_LITERAL_STRING("+3"));
+      else
+        font_size.Assign(NS_LITERAL_STRING(""));

if not, the comparison statements should be of the form: 

if (font_size.EqualsLiteral("xx-large"))

* NS_GetLocalizedUnicharPreferenceWithDefault(prefBranch, "msgcompose.font_size", NS_LITERAL_STRING(""), font_size);

why don't we just read the pref directly from the pref service instead of using this localized unichar preference routine. I don't think this pref is a localized pref.

I haven't looked at the mime part yet, I'll try to get to that soon! thanks for taking a look at this.

Comment 15

[notagain]

this still happens with tb 3.0b2pre nightlies. both the reply and forward header cases. any work done? will this be solved anytime soon (3.0 final perhaps)?

Comment 16

[Antony Mawer]

This would be a welcome fix in Thunderbird 3 -- using a sans serif font (eg. Arial) in Thunderbird at the moment looks very unprofessional, as whenever you reply you end up with a serif font for the "XYZ wrote" text...

Comment 17

[gene c]

I have same problem using 3.0b2 nightly as of 20090513.

Also - the font size selector is too coarse - medium or large - we really need to be able pick the font size we use.

thanks.

Comment 18

[Rick]

Agree fully with comment #17: please create a dropdown with font sizes to choose from instead of 'larger' and 'smaller' buttons.

Comment 19

[gene c]

Bug is still there with build as of 20090528 .. both bugs - the font not suddenly switching away from user specified default to something else and also the inability to choose a font size.

Comment 20

[Gary Kwong [:gkw] [:nth10sd] (NOT official MoCo now)]

Comment on attachment 260269 [details] [diff] [review]
Updated patch that addresses TT special case

Obsoleting due to rejected review.

Comment 21

[gene c]

 I dont understand comment #20 at all.

 I think the bug is this:

   Hit reply - start typing - your preference font/size is chosen - in mid type is switches to something else - different font different size.

    My default is sans-serif/large - it usually switches to variable/medium.

  
  End resault is reply contains new text 1/2 in preference compose font and 1/2 in thunderbird default font.

   WHy is this not a bug - this happens with this build:

Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1pre) Gecko/20090617 Lightning/1.0pre Shredder/3.0b3pre ID:20090617031506

  Which is hardly an obsoleted build.

Comment 22

[Mark Banner (:standard8)]

(In reply to comment #21)
>  I dont understand comment #20 at all.
...
>   Which is hardly an obsoleted build.

The comment didn't say the bug was obsolete, it said the *patch* was obsolete.

Comment 23

[gene c]

Ooooohhhh silly me .. 

sorry

:-|

Comment 25

[Josh]

This bug occurs even if you just click an area with a non-default font.  It is amazingly frustrating.  It feels like playing Minesweeper when all I want to do is write an email.

Comment 27

[Michael A. Pasek]

Bug 533613 was DUP'd to this bug because the reporter of Bug 533613 agreed that the symptoms and STR described in Bug 273622 matched what he was trying to report.  It is not clear to me that this bug report (203810) actually describes those same symptoms, nor that the proposed fix will fix the problem noted in the Description in Bug 273622.  Therefore, if the patch for this bug WILL NOT address the problem noted in Bug 273622, I respectfully request that the assignee of this bug:
a) Reopen Bug 273622; and,
b) Mark Bug 533613 as a duplicate of Bug 273622.
Doing so will ensure that the problem noted in Bug 273622 DOES get fixed.

Comment 28

[Neville Hillyer]

Can we assume that this is an HTML problem only? If so I have failed to find where it is clearly stated.

I am not sure if my remarks below will be of any help to those working on this bug or users who end up here.

I seldom compose with HTML and don't see this bug 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.

Comment 29

[Peter]

A variation on this is that it also loses the default font when I click on the subject line and then click back to my text. 

Although I love thunderbird, about once a month I search for ways to get outlook to replicate my most beloved add-on's because it is so frustrating to use an e-mail program that will not let me control my font style (and size).

Comment 30

[gene c]

Bug is still here in 3.1.7 nightly as of last night ... 

amazing this bug is over 7 years old ... 

do the experts know what to fix is yet ?

font flipping makes for ugly emails ;-( ...

Comment 31

[Mike Cloaked]

Truly astounding as this bug comes up to almost 8 years old - I am using 3.1.10pre and this bug is still present - it bites me pretty much every week - sometimes on the next line when composing and sometime in the middle of a line and yes with html email.....  

Surely someone could give this bug a little love and sort it out once and for all?

Comment 32

[gene c]

also bug is still in todays Miramar 3.3a4 pre ... bit sad really .. :-(

Bug is assigned to nobody presently ... there were some suggestions on how to fix this in 2007 ... may not help tho ..

Comment 33

[Neville Hillyer]

I doubt that this 8 year old bug will ever be fixed.

Perhaps users should use text rather than HTML.

Comment 34

[John Hupp]

I have come to the edge of abandoning Thunderbird due to this 9 1/2 year old bug.  People reply to my replies and I see that the format of what I sent them makes it look like it was written by a 7-year old with crayons.  It's a hodgepodge of two different fonts/sizes -- embarrassing and unprofessional.

Is there a work-around or a fix?  (People working with TB 3 in 2010 had some success with setups involving the add-ons Quote & Reply and QuoteandComposeManager.  But before I wade into those waters I would like a little assurance that it can be made to work.)

Comment 35

[Neville Hillyer]

A while ago I switched my PPC to SeaMonkey 2.13 which overcame a whole raft of bugs although I am not sure about this particular bug.

Details at: http://links.zero.eu.org/seamonkey/

Comment 36

[John Hupp]

At seamonkey-project.org, the intro says "Under the hood, SeaMonkey uses much of the same Mozilla source code which powers such successful siblings as Firefox, Thunderbird, Camino, Sunbird and Miro."

So unless they forked development of the email client code, a first guess would be that you share this bug.

Comment 37

[Mike Cloaked]

Yes having this formatting bug is very tiresome indeed as a long time user of Thunderbird and it is still very much a bug in version 18a2!

Comment 38

[Neville Hillyer]

I have not been able to replicate the originally described bug with the latest SeaMonkey. Is it accurately described? Should instruction '1' read 'below' rather than 'above'?

I can say that clicking elsewhere such as in the subject line picks up the default font but this was not the originally described bug.

Comment 39

[John Hupp]

It's true -- I would say that various comments round out the description of the various manifestations.  The original bug report captured fewer of those, but as far as I know it's accurate as far as it goes.

Comment 40

[Mike Cloaked]

https://bugzilla.mozilla.org/show_bug.cgi?id=782215

is relevant/related to this bug too.

Comment 41

[Neville Hillyer]

(In reply to John Hupp from comment #39)

I prefer to be able to test a single accurately described bug. As I said, I am unable to replicate the original bug with the latest SeaMonkey - perhaps it has been fixed.

Comment 42

[John Hupp]

(In reply to Mike Cloaked from comment #40)
> https://bugzilla.mozilla.org/show_bug.cgi?id=782215
> 
> is relevant/related to this bug too.

I see that that bug is not assigned to anyone either.  Perhaps if a developer ever digs into it, a single cause will be found for the similar bad behaviors.

Comment 43

[paul]

(In reply to Neville Hillyer from [url=https://bugzilla.mozilla.org/show_bug.cgi?id=203810#c41]comment #41[/url])
I don't know SeaMonkey, but I can confirm this is still an issue in Thunderbird 16.0.2 (latest version on the 'release update channel'). And I don't know how recent a build TB 18a2 is, but Mike Cloaked reports (in [url=https://bugzilla.mozilla.org/show_bug.cgi?id=203810#c37]comment #37[/url] above) that it is still an issue for him.

As for a "single accurately described bug" I think this has enough related manifestations (e.g., Mike Cloaked comment #40) to make that a difficult precondition.

My 'workaround' used to be to type a word (usually the person's name to whom I was writing), hit Enter, type my name on a new line(i.e., the last thing in the message) and then move up to the end of the first line, hit Enter again, and type (and edit) the body of my message. This workaround worked (i.e., preserved formatting) until v. 15 (I think... It is sometimes difficult to tell when something like this manifests, because, from all appearances, the message looks OK [I confess, I don't often check the formatting of the messages in my Sent folder]. I only began noticing it in certain replies from others that had included my message in the reply).

Comment 44

[Mike Cloaked]

OK I did a test which seems to throw up the inconsistent font issue is a totally reproducible way - and the test is very simple indeed. I am using version 18a2 linux 64 bit version from 4th November but this test can be applied to any version that other testers following this bug can also try.

The test is as follows:
1) Click "Write" to begin composing a new mail. My default font is set as medium, and sans-serif.
2) Now type direct into the main text box "This is a test " - 
3) Now highlight the text you have just entered with the mouse and right click and copy.
4) With the cursor set at just after the last space in the text entered now right click and select "Paste without Formatting"

The result is that the two phrases which should be identical are now of different font size.

I will attach a screenshot in a sec showing the two different fonts in this text as highlighted.

Comment 45

[Mike Cloaked]

Attachment: image showing the result of the font inconsistency

Comment 46

[Mike Cloaked]

By the way I use a simple html signature file - but I don't know if that makes any difference. Also the box showing the font changes from sans-serif to "mixed" as soon as I highlight the combined text in the test from comment #44

Comment 47

[Neville Hillyer]

(In reply to paul from comment #43)

Send it to yourself and post the received HTML source here so that we can see what happened.

Comment 48

[maybe-the-one]

Folks, the reason most or all of these manifestations(created by numerous different steps--which make them SOUND LIKE different bugs) is this...

when you first type "This is a test " or what ever at the top of the entry area, what is really there is
"This is a test " {/font}  
with [] instead of {} of course.

Now, if at that point, you move the cursor ANYWHERE, for any reason, and then click it back at the end of the line, or if you insert text, you are now typing to the right (after) the {/font} tag, and being outside the end-font tag, will now be using the default font.

Comment 49

[gene c]

Sort of - I have changed the default font to large sans-serif (LSF) via preferences->display->default font. This is not thunderbird's internal default (TIF).

What I find is that in spite of my internal font being LSF  tb will switch back to TIF - that is most certainly a bug. I should only get my LSF. 

The bug for me is that my [changed] default font is sometimes respected and sometimes not ...

Comment 50

[Neville Hillyer]

Too many different issues are getting confused here. The only common thread I can see is dissatisfaction with TH's less than perfect WYSIWYG editor.

I have spent the last 15 years manually editing HTML so I can see some of the compromises TB's designers have made.

It would be useful if all contributors tried to understand the HTML used which is why I have tried to get people to post to themselves and then examine the incoming HTML.

Comment 51

[paul]

(In reply to Neville Hillyer from comment #47)
> (In reply to paul from comment #43)
> 
> Send it to yourself and post the received HTML source here so that we can
> see what happened.

I'm not smart enough to be able to recreate the problem, but here's a bit of HTML source from a message where this did go wrong:

<br>
      <meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
      <font face="Tahoma">Some text here.</font> Followed by more text here.<br>
      <br>
      Paul<br>

Everything after </font> is smaller than that which is before it. Let me know if you need more of the HTML source stuff and I'll work at removing 'particulars' (i.e., addresses, etc.)

Comment 52

[maybe-the-one]

(In reply to paul from comment #51)
> (In reply to Neville Hillyer from comment #47)
> > (In reply to paul from comment #43)
> > 
> > Send it to yourself and post the received HTML source here so that we can
> > see what happened.
> 
> I'm not smart enough to be able to recreate the problem, but here's a bit of
> HTML source from a message where this did go wrong:
> 
> <br>
>       <meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
>       <font face="Tahoma">Some text here.</font> Followed by more text
> here.<br>
>       <br>
>       Paul<br>
> 
> Everything after </font> is smaller than that which is before it. Let me
> know if you need more of the HTML source stuff and I'll work at removing
> 'particulars' (i.e., addresses, etc.)

That is exactly what I described in my post previously.  I looks strongly as if you moved the cursor after typing 'Some text here' (click back to correct a spelling, insert some text, or something like that).  Note that the 'Followed by more text here' is AFTER the [ /font ] tag, which ended your selected font at that point.

Comment 53

[gene c]

Exactly - so why does it not continue using the font the user defined as their default font? When the user has defined a default font it should be used whether or not they moved their cursor. 

Remember the bug here is having a user preference set for their default font - and finding this is not properly honored in above situation(s).

Comment 54

[John Hupp]

OK, so now we see how the bad behavior is being executed in HTML.

Maybe I'm misreading some of the comments, but is anyone here implying that this is not a bug?  That a user-set default Composition font should not be respected as the default in cases 1 through N?  Gene C gets right back to the main point: This is a bug.

And as I posted earlier, it's a bug that has me sending out unprofessional, embarrassing emails.  If I can't find a solution, I expect that I'll abandon Thunderbird.  A shame, since I'm an open source devotee, but it's more important to me that it works right.

But first, on the topic of finding a solution: I observed today the "VOTE" feature in the header of this bug report.  I clicked on that, then the Change Your Vote check-box, then Save Changes.  Each of us who is registered here and logged in apparently gets 1000 votes, presumably to highlight which bugs we think are most important.  My vote just bumped the count up to 21, but that still places it in the Normal Importance category.  LET'S ALL VOTE.

Comment 55

[maybe-the-one]

No, no one is saying it is not a bug.  I was just showing what was happening that was causing (at least this particular manifestation) to happen.

You are at risk of invoking the bug if you do anything other than straight, continuous typing.  Hitting Enter does not invoke the bug.

A trick to help solve it is to hit Enter several times as the FIRST thing you type.  This moves the hidden [ /font ] tag down the page a bit.  So, if you move the cursor, then move it back at the end of your actual typing, it is still above the tag.

And yes, do VOTE for this.

Comment 56

[Mike Cloaked]

Let's face it very few people will type a straight uninterrupted email and hit send - and the longer the text the more likely it is that one will go back and change sentences and add  or remove parts of what had been typed - hence any reasonable compose facility should accommodate that so that the best experience can be enjoyed by the user rather than ending up that the user is irritated and frustrated by the experience. So basically is is poor design and not showing proper considerable of normal user experience. So yes it should be fixed and yes everyone seeing this report should vote for it to get sorted out!

Comment 57

[Mike Cloaked]

It might also be nice if users voted on the related bug at https://bugzilla.mozilla.org/show_bug.cgi?id=782215 also.

Comment 58

[John Hupp]

Yes, I agree that your observation can help users work around the bug in many cases.

But there seemed to be an implication in some comments that "default font" had a rather limited meaning, and that the program was therefore working per design.

I'll grant that I may have misinterpreted to arrive at that, but since the bug is 9 1/2 years old, one has to wonder if the development team isn't aware that this is not only maddening but an actual show-stopper for a number of users, or if they are aware and simply disagree with that assessment.

In any case, voting to bump up the Importance to something above Normal is one of the things non-developers can do to try to get some qualified attention directed at this.

Comment 59

[John Hupp]

My Comment 58 was in reply to maybe-the-one's Comment 55.

And regarding Mike Cloaked in Comment 57: Done!

Comment 60

[Mike Cloaked]

(In reply to maybe-the-one from comment #55)

> A trick to help solve it is to hit Enter several times as the FIRST thing
> you type.  This moves the hidden [ /font ] tag down the page a bit.  So, if
> you move the cursor, then move it back at the end of your actual typing, it
> is still above the tag.

The way that the composer should work is that it "automatically" moves the [/font] tag to immediately before the signature or if no signature then keep it at the end - and then any changes to the fonts "initiated" by the user whilst composing should have their own [font] and [/font] embedded around any text with a different font to the default font.

Also another work around is to simply enter all the text and corrections/additions/subtractions and then highlight the entire text up to the signature and then change it with the format->size-> options or other formatting options. However the point is that you should not need to have a workaround if the behaviour was sensible in the first place!

Comment 61

[maybe-the-one]

Of course it should work in the first place.

I don't understand all these comments saying that.  That is what the whole thread is about!

People post some method to make life easier, and immediately the response is "but it should work without that."  Duh, of course.  That doesn't make the suggestions useless, such as the Enters before typing, or highlight and set the font after typing, both of which are tools for living with the bug UNTIL IT IS FIXED (if ever).

Comment 62

[Mike Cloaked]

Just an aside comment - but the gmail compose window in the new google webmail interface works perfectly well for html mail and does not have the problems we have in Thunderbird - OK that is a web interface but it does mean that it is possible to have a compose window that handles html mail perfectly well!

Comment 63

[Neville Hillyer]

I would rather see a simpler totally different approach adopted by the designers:

Always use the defined font style (this would be the default font style until changed by the tool-bar) irrespective of cursor position or history.

I think most editors do this.

It would have the disadvantage that any text added to the middle of a paragraph would use the current font style rather than that of the paragraph but it would be immediately visible and easy to correct especially if a 'change current style to that of highlighted text' control were provided.

Some thought would have to be given to copy/pasted styled text - perhaps provide a user option to use current style or retail original style.

Comment 64

[Neville Hillyer]

(In reply to Neville Hillyer from comment #63)

Sorry about the silly typo in my last message: please read 'retain' for 'retail' near end.

Comment 65

[Mike Cowperthwaite]

Mike Cloaked, nothing in the problem you're discussing has anything to do with "font style in prepopulated text," which is the main stated condition of this bug in the title.  Not to defend the HTML editor, but your report does belong elsewhere.

It should be immediately obvious that the text "xyz wrote..." in an HTML reply does not follow the composition preferences.  That wasn't part of the initial bug report here, however, and it's my fault for poorly re-summarizing this bug in 2007.  The lack of preferred formatting on the attribution line should be a separate bug (and maybe it already is).


In comment 7, I referred to bug 245581 comment 1, which describes the underlying problem for that bug and the primary symptom of this bug: text that I'm typing not following my font preferences.

The original steps in comment 0 do not reproduce in TB 16.0.2 (Win7/64).  However, the reported symptom is still easy to observe.  Here are the STR, from comment 0, with only the fourth step modified slightly:

1. Launch app - set to reply above quoted text (default for commercial builds)
2. Change your mailnews preference for composition to another font style.
3. Click Reply to a message someone sent preferably with the default font style.
4. Start typing (note you will see your default style), backspace all the way 
to the left margin; press the Down arrow, followed by the Up arrow, and start typing again.

Actually, the initial typing followed by backspace is not required.  What is required is moving the cursor away from its initial position with an empty user-typed text body -- which is only achievable if there is some prepopulated text.

Comment 66

[Neville Hillyer]

(In reply to Mike Cowperthwaite from comment #65)
Your STR with up/down arrow is totally different to the original report. I can probably replicate your STR with the latest SeaMonkey whereas I could not replicate the original STR with SeaMonkey. With what authority do you presume to alter the original STR? If the original STR cannot be replicated it might be best to close this bug report and start another one.

Comment 67

[Mike Cowperthwaite]

(In reply to Neville Hillyer from comment #66)
> (In reply to Mike Cowperthwaite from comment #65)
> Your STR with up/down arrow is totally different to the original report.

I don't agree.  The essential difference is that hitting backspace in an "empty" message body (no user typing from beginning of the message) no longer "moves" the cursor away from the insertion point, where it used to.  The loss of user-preference formatting is predicated on that movement.

Try following the dupes and seeing what they have to say about.  Some of those dupes might be mistaken -- and, as I said, the summary of this bug isn't really to the point.


> With what authority do you
> presume to alter the original STR? If the original STR cannot be replicated
> it might be best to close this bug report and start another one.

I was granted bug-editing privileges in 2003.  I remember when Esther was active in Bugzilla.  I put several boatloads of work into bug triage from 2003 to 2007.
You?

I don't mind at all if one or more new bugs are started to sort this one out.  Given the state of this bug, that probably *would* be best.

Comment 68

[Neville Hillyer]

(In reply to Mike Cowperthwaite from comment #67)
I would like to see a new bug report started. Although I have followed this bug with interest I am not the best person to write it as I only switch on HTML to test this bug. I normally send text only. I do however have many years experience of hand crafting HTML for web pages so probably have an understanding of the underlying issues.

Unlike so many of these reports any new bug report should have an STR saying that HTML should be activated in account settings to make it clear that the issue only affects HTML emails and not text emails.

Comment 69

[Mike Cloaked]

I started what is perhaps a more relevant new report a few months ago at https://bugzilla.mozilla.org/show_bug.cgi?id=782215 but not much in the way of replies to that have appeared!

Comment 70

[Ronald Killmer]

The basic issue reported in comment #0 involves the attribution line being a different font face than the User configured body composition font. 

"If the user backspaces in the first line all the way to the left, the newly typed text picks up the font style of this pre populated text." I quote this for two reasons. Esther is referring to the attribution line as "pre populated text". Then the back space action and resulting font change is a bug occurring because of a whitespace/end-of-line bug in the editor/composer code library.

IIRC, it was TB12 had a sudden appearance of a bug that was being masked by the Editor whitespace bug. The essence of the bug was EOL was incorrectly handled as whitespace in some cases. With Editor patched, TB Devs patched their TB bug.

We still have font face changing issues with TB and there are current bugs open.

The different font face of the attribution is a bug itself and independent of this bug report.

Speaking as a TB bug triage team member, I think this bug should be closed since the bug in Editor that was fixed has altered the code-base so the original conditions are changed.

Comment 71

[Neville Hillyer]

(In reply to Ronald Killmer from comment #70)
I agree will all you say and would prefer it to be closed. It appears to wonder over a range of issues unrelated to the original STR.

Comment 72

[Ronald Killmer]

Added white-board note to close 1/1/2013

Comment 73

[paul]

(In reply to Ronald Killmer from comment #70)
> 
> We still have font face changing issues with TB and there are current bugs
> open.

I'm fine with closing this bug if it is fixed. But it would be wonderful to be pointed to the relevant bug(s) that are open on 'font face changing' issues. I'd be pleased to add my vote to them.

Comment 74

[John Hupp]

I too would very much like to be pointed to the relevant font changing bugs so that I could vote up their importance.

Comment 75

[maybe-the-one]

(In reply to John Hupp from comment #74)
> I too would very much like to be pointed to the relevant font changing bugs
> so that I could vote up their importance.

INDEED...a list of all bugs having to do with font changing when it should not would definitely be helpful.

Comment 76

[paul]

I found #782215 "Font size change causes inconsistent size changes to occur" (https://bugzilla.mozilla.org/show_bug.cgi?id=782215). That's a start...

Comment 77

[paul]

Arrrg! I meant to point to this one: #756984 "Changing location in editor doesn't preserve the font when returning to end of text/line" (https://bugzilla.mozilla.org/show_bug.cgi?id=756984). Mike Cloaked already pointed us to 782215 in Comment #40...

Comment 78

[Phoenix]

Resolved per whiteboard, Comment 70 and following comments