Open
Bug 782215
Opened 12 years ago
Updated 2 years ago
Font size change causes inconsistent size changes to occur
Categories
(Thunderbird :: Message Compose Window, defect)
Tracking
(Not tracked)
UNCONFIRMED
People
(Reporter: mike.cloaked, Unassigned)
References
Details
Attachments
(5 files)
User Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.1 (KHTML, like Gecko) Chrome/21.0.1180.75 Safari/537.1
Steps to reproduce:
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.
Actual results:
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
Expected results:
Font size should have been changed uniformly across all of the text that had been highlighted.
Reporter | ||
Comment 1•12 years ago
|
||
version Mozilla/5.0 (X11; Linux x86_64; rv:16.0) Gecko/16.0 Thunderbird/16.0a2 ID:20120810042011
Comment 2•12 years ago
|
||
Have had the changing font problem for years. My experience has been the font goes to a smaller size. Unpredictable when it will happen but simply pausing for a short time when composing a message in Thunderbird will often cause it when you resume typing.
You can then go back, highlight the problem text change to what you intended and the message. When you then receive a response the effected text is back to the previous size. Strange, amateur coding.
Reporter | ||
Comment 3•12 years ago
|
||
I have been testing with version Mozilla/5.0 (X11; Linux x86_64; rv:16.0) Gecko/20120813 Thunderbird/16.0a2 ID:20120813042011 but not had a recurrence. I will keep testing over the coming days and report further in due course.
Comment 4•12 years ago
|
||
Still a problem, but I've found a workaround. When the fonts change while composing in Thunderbird stop, change to desired/correct size, SAVE, before sending. I've been sending a BCC to another account and the fonts maintain the desired size. If you don't SAVE before sending then they often show up at the other end as the changed size even after you had changed it to desired size before sending, but the use of a SAVE before sending seems to keep the desired size both going and on replys.
Others experince?
Reporter | ||
Comment 5•12 years ago
|
||
It may be a workaround but not really user acceptable - I am using 17a2 and what I do is to type a text and wait until I have finished before hightlighting all of the text in the compose window and choosing a font size - that seems to have been consistent and works fine - previously if I made changes to the text after doing this then the text can be inconsistent size after sending.
I am still unclear which versions of Thunderbird have the current patch in?
Reporter | ||
Comment 6•12 years ago
|
||
There still seems to be a font size consistency problem in v18a2 as well.
I also tested the font issue by simply typing a long reply to an incoming email, and during that process going back in the text to change some of the words - after typing about two pages I noticed that the UI was showing missing characters and red squiggly lines at various places in the composed text. Sending at that point gave several sections of missing text and some corrupted text (words that had missing letters and some jumbled apparently at random).
I get compose font issues very regularly although much of the time I can highlight the entire composed text and use Format->Size and select a font size which then fixes the highlighted text. However simply typing, including going back to edit text, often gives faulty display of the text once a page or so has been written.
So there are still serious issues making composing html emails frustrating at best, and presumably not impressing too many of the users who comes across this bug regularly.
Reporter | ||
Comment 7•12 years ago
|
||
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.
Reporter | ||
Comment 8•12 years ago
|
||
Reporter | ||
Comment 9•12 years ago
|
||
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 #7
Comment 10•12 years ago
|
||
There is a bug report similar to this one at:
https://bugzilla.mozilla.org/show_bug.cgi?id=203810
Comment 11•12 years ago
|
||
(In reply to Neville Hillyer from comment #10)
> There is a bug report similar to this one at:
>
> https://bugzilla.mozilla.org/show_bug.cgi?id=203810
That is a similar bug that existed because of a whitespace bug in Editor which has been fixed.
Comment 12•12 years ago
|
||
I reverted to an older version because of this problem (which I initially described in bug 802190). Version 15.0.1 does not have this problem (for me at least).
Would it help if we pinpointed at which version exactly the problem was introduced?
Comment 13•12 years ago
|
||
Mike, the steps you show in comment 7 are causing the manifestation of this version of the bug(s?) because at step 4, you moved the cursor back to the end of the previous text.
As I have stated in other bug threads, this will change the typing point to be AFTER the hidden [/font] html tag even though it appears as you look at it in the typing space to be right after the last text character; in the html, it is not...it's now after the tag--thus invoking the default font rather than the specified font (unless for some reason you are still inside some other font specification for a div or span, etc--then you would revert to THAT font rather than default).
Comment 14•12 years ago
|
||
I guess it is another bug than mine after all then.
But maybe-the-one: even though that is probably indeed the reason of the bug, it is NOT what should happen.
The best way to fix this is as follows: when the cursor appears at the end of a line, for ANY reason (click on the right of it, using arrow-left on the line below it,...), the cursor should in reality be placed on the left of any closing tags present there. With a simple resursive method: if you see a closing tag at the end, move the cursor to the left of it; if you still see a closing tag then, move to the left of it again, etc. If however there is a space or an opening tag or anything else at the end of the line, just leave the cursor there.
Something similar should happen at the start of a line: if the first thing on a line is an opening tag, put the cursor after that, until you don't have an opening tag on the cursor position anymore.
All that said though, I can't reproduce this problem in Thunderbird 15.0.1. Perhaps this issue was (re?)introduced in version 16 then. The only similar thing I can reproduce is if I "select all" and then delete: then the font is lost. I believe the default font should be put back in this sort of case (i.e. if a message is reduced to nothing, or just a <br>).
Comment 15•12 years ago
|
||
Actually, "this sort of case" (at the end of my previou post) should rather be: as soon as the first opening tags in the message are removed. The main point is simply that one should never end up with an unstyled font; the default font should always be ... the default.
But I truly believe the team should seriously consider whether integrating another HTML editor would not make more sense, as it may well solve many more bugs at the same time.
Comment 16•12 years ago
|
||
Using TB 17.0 on Windows 7 SP1 64-bit.
Just upgraded from a very old version. This annoying bug has apparently been around since 2003! When I compose a message and use the backspace key TB throws in a font tag to change the size, so when I view the HTML of the message I get text that looks like this:
<br><br>If you <font size="+1">need complex <font size="+1">conditions like Answer = A or <font size="+1">D, then <font size="+1">it gets complicated. Page <font size="+1">Conditions</font>
</font>
</font>
</font>
</font>
need to be in separate Groups to be evaluated with OR<font size="+1">; conditions in the same <font size="+1">G</font>
roup</font>
are evaluated w<font size="+1">ith AND</font>
, so both conditions must be met for the condition to be true. The Skip To option <font size="+1">can be confus<font size="+1">ing too. You may need to experi<font size="+1">ment to get it to work like you want.</font>
</font>
</font>
Comment 17•12 years ago
|
||
Confirm the previous post. Using the backspace key inserts additional font tags every time it is used...
<body style="font-family: Calibri; font-size: 19px;" bgcolor="#FFFFFF" text="#990000"><font face="Calibri">##############BSSP<font face="Calibri">xxxxxxxxxxxxxxxxxx<font face="Calibri">yyyyy<font face="Calibri">zzzzzzzz</font></font></font></font></body>
Comment 18•12 years ago
|
||
I'm not sure the bug has "been around since 2003", though. As mentioned before, I downgraded to 15.0.1, and this behaviour no longer appears for me. See below: I hit backspace every time I switched to another letter. In version 16 or later, it would have produced the redundant tags as described above.
<font size="-1"><font face="Verdana">ccccccccdddddd[text
inserted]ddddddeeeeeefffff</font></font>
I.e., as it should be. So if the bug was really present in 2003, it has been solved since, but reintroduced somewhere around the time version 16 was released.
Comment 19•12 years ago
|
||
(In reply to bugzilla from comment #18)
> I'm not sure the bug has "been around since 2003", though. As mentioned
> before, I downgraded to 15.0.1, and this behaviour no longer appears for me.
I just tried rolling back to 15.0.1 and got the following results:
Date: Tue, 27 Nov 2012 11:20:26 -0800
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:15.0) Gecko/20120907 Thunderbird/15.0.1
MIME-Version: 1.0
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: 8bit
<html>
<head>
<meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<font face="Tahoma">I just want to test the new functionality of </font>Thunderbird
15.0.1. Any better or not?<br>
<br>
Paul<br>
Everything from 'Thunderbird' on has picked up the font information (smaller size, different font) from the message I was replying to. Obviously, that's not what I'm after... So something is still lurking in 15.0.1. Or is it in my profile somewhere?! Because I uninstalled 17.0 and installed 15.0.1, but I'm using the same profile as before.
Comment 20•12 years ago
|
||
Well, that's a different bug: what I was refering to was tags being repeated when they're not needed, but what you are reporting is a tag ending too soon.
What I mean: <font>Hell<font>o, here are t<font>oo many tags<font>.</font></font></font></font>
==> the formatting is repeated many times, resulting in redundant tags. Sometimes it does cause font problems, butthey are difficult to reproduce.
What you mean: <font>Hello, here are t</font>oo many tags.
==> the formatting is not repeated, and the major problem is that the extra text is put after, instead of before, the closing tag.
Looks to me like the second (your) bug was solved by a patch that (re)introduced the first bug (mine).
Comment 21•12 years ago
|
||
(In reply to bugzilla from comment #20)
> Well, that's a different bug: what I was refering to was tags being repeated
> when they're not needed, but what you are reporting is a tag ending too
> soon.
>
> What I mean: <font>Hell<font>o, here are t<font>oo many
> tags<font>.</font></font></font></font>
> ==> the formatting is repeated many times, resulting in redundant tags.
> Sometimes it does cause font problems, butthey are difficult to reproduce.
>
> What you mean: <font>Hello, here are t</font>oo many tags.
> ==> the formatting is not repeated, and the major problem is that the extra
> text is put after, instead of before, the closing tag.
>
> Looks to me like the second (your) bug was solved by a patch that
> (re)introduced the first bug (mine).
Well, colour me confused... I was commenting on another bug, but it seemed that we were pointed here. Maybe I lost track of which was which (entirely possible!) All I want is my messages to be sent like they look before I send them. None of these (software introduced) 'changes' appear until it goes to the recipient. If I type in a particular font at a particular size--and don't change them--I want them to stay that way when I click Send.
Comment 22•12 years ago
|
||
I absolutely agree. Here's a tip: do "select all", "cut", and "paste" (a.k.a. control-axv). It's rather cumbersome to do this with every single email you compose, but as far as I've tried, this does reveal any erroneous formatting that has occured.
In another bug, I described that as "What I See is not What I Get". In other words, as it stands now, the Thunderbird composer is NOT a WYSIWYG editor, even though everyone is expecting it to be (including the developers, I'm sure).
Comment 23•12 years ago
|
||
(In reply to bugzilla from comment #20)
> Well, that's a different bug: what I was refering to was tags being repeated
> when they're not needed, but what you are reporting is a tag ending too
> soon.
>
> What I mean: <font>Hell<font>o, here are t<font>oo many
> tags<font>.</font></font></font></font>
> ==> the formatting is repeated many times, resulting in redundant tags.
> Sometimes it does cause font problems, butthey are difficult to reproduce.
[...]
That's bug 812638
Comment 24•12 years ago
|
||
bug 812638 was created less than 2 weeks ago... that/this issue has been around since much longer, and has been mentioned in various bugs. I don't really understand why that new bug has been assigned to someone and been marked as 'NEW' while this one - 15 weeks old as opposed to 2 - is still 'UNCONFIRMED'. In any case though, good thing someone's looking at it, because if that one is fixed, there's a chance the other related bugs are also solved (if only partly).
Related bugs (in my opinion) are among others bug 798868 and bug 802190.
I stand by my suggestion to integrate an other existing HTML editor (Kompozer, CKEditor,...), rather than fixing the countless small bugs in the current one. There are excellent editors out there, and even though I realise integrating a new editor would take considerable work, I am convinced it would still be faster and more efficient than handling the long list of small bugs.
Comment 25•12 years ago
|
||
This has been here for YEARS...if you believe the bug is "fonts change when they should not." Yes, there must be hundreds of versions of "steps to reproduce," but the end result is always the same--fonts not what they are supposed to be.
A few of the volunteer developers have written about this is the past in other threads of SOME version of this bug. They have said the composer code is in C and not many current devs are proficient in that language. Worse, the code was modified by many different people over the years, is horribly documented, and thus is almost impossible to work on.
Assuming that is the case, I concur with the idea of at least LOOKING AT replacing the composer with something already proven. I know it would not be just a drop-it-in situation, but it probably is the path of least resistance.
Somehow, the community supporting Thunderbird needs to collaborate long enough to internally discuss this possibility. It also would be nice to clue in us users with status reports regularly.
Comment 26•12 years ago
|
||
(In reply to maybe-the-one from comment #25)
> This has been here for YEARS...if you believe the bug is "fonts change when
> they should not." Yes, there must be hundreds of versions of "steps to
> reproduce," but the end result is always the same--fonts not what they are
> supposed to be.
>
> A few of the volunteer developers have written about this is the past in
> other threads of SOME version of this bug. They have said the composer code
> is in C and not many current devs are proficient in that language. Worse,
> the code was modified by many different people over the years, is horribly
> documented, and thus is almost impossible to work on.
As a user, the various font-changing bugs have driven me crazy and are causing me to consider abandoning Thunderbird. So I agree, if this editor seems too difficult to fix due to reasons like the above, then replace it.
Reporter | ||
Comment 27•12 years ago
|
||
Does it require an RFE to request that the editor should be replaced by one that actually works?
Comment 28•12 years ago
|
||
I've bookmarked 17 bug numbers dealing with font problems. Want the list?
Comment 29•12 years ago
|
||
I say post it. I'll add my vote for any that I haven't already voted up.
Comment 30•12 years ago
|
||
Here's the list:
Bugzilla bugs dealing with Font problems:
(Note: Some of these bugs are marked "Resolved"; a number of the bugs are marked duplicates of others listed. I've added a few titles when the bug doesn't seem to involve actual unexpected font changes or inserted tags.
98763 Mail toolbar doesn't display current font size
203810
250539
308437 Add a combobox to set absolute font size to the composition toolbar
480647 execCommand('fontSize') doesn't change font size if content font size is specified in css
536613
590640
601658
606668
617878 There is no way to control the default font in a HTML signature
756984
757371
782215
798868
799893
802190
812638
Comment 31•12 years ago
|
||
Hey Aryeh - does this sound like an Editor bug to you? If so, do you think you might have some cycles to poke at it?
Flags: needinfo?(ayg)
Comment 32•12 years ago
|
||
It sounds like it's almost surely a bug in either editor or selection code, yes. If someone can give me clear steps to reproduce in Firefox, e.g. in the Midas demo:
http://www-archive.mozilla.org/editor/midasdemo/
then I can take a look. I suspect different people here are talking about entirely different bugs. Comment 16 definitely looks like bug 812638. Comment 7's steps to reproduce look good and probably identify a real bug, but don't work in Firefox as-is, because there's no "Paste without formatting" context menu option. Comment 13 is very possibly true, and comment 14 is exactly right: we should ideally make the caret always stick to adjacent text nodes and not fall in between two tags.
Be warned that even if the bug is identified more clearly, it might not be worth our while to accept a fix, as long as we have no one consistently available to address potential regressions in a timely fashion.
Flags: needinfo?(ayg)
Comment 33•12 years ago
|
||
Hello,
this is not a bug solver comment but a simple user (with no tech experience) comment. Sorry for that.
With respect to the status of Bug 782215 I can say that what it is reported in the Description field exactly happens in Windows since (I can't recall precisely) probably even before August 2012.
The net result is that Thunderbird (I am now using 17.0.5 on Windows) messages may look really unprofessional.
Don't get me wrong: I love each and every single bit from Mozilla. That's why I am posting my feedback: hoping this bug can be resolved asap (even if I am aware of the priority changes applied by Mozilla for Thunderbird in terms of development).
My "feeling" is that spell checking might also be involved.
As far as my experience is concerned Thunderbird spell checking has also had unresolved problems since quite a while: sometimes, after having typed a correct word, Thunderbird "brakes" the correct word by underlining all the letters except the first one. In order not to have this annoying incorrect underlining I switch to another language spell checking and then back to previous one and this "restores" the "normal" behaviour.
Some times the sections with different font sizes (and maybe also different font type? I haven't checked) reported in the Description field of this bug coincide with the points where the "braking and subsequent incorrect underlining" happens.
Comment 34•12 years ago
|
||
Change
<the points where the "braking and subsequent incorrect underlining" happens>
with
<the points where the "breaking and subsequent incorrect underlining" happens>
Comment 35•11 years ago
|
||
@Aryeh:
I went to the Midas demo, and pasted an example of text that was changed out from under my current edit by mousing out of the editor and then back in. I'm also attaching a screencast of the behavior and a screenshot of the Midas demo display.
<font face="Verdana">In my profile I find the "Local folder username," with a description</font> of "the font size is not correct."<br> <div class="moz-signature">-- <br> <img alt="G. Richard Bellamy" src="http://www.terradatum.com/metrics/images/rbellamy_sig.png"> </div>
Comment 36•11 years ago
|
||
Comment 37•11 years ago
|
||
Comment 38•11 years ago
|
||
My problem is when I copy a paste some text from another source into my email. That pasted text may be smaller or larger that the font I've been using, but when I want to make everything uniform when I'm done, I can't do it. Why not have a simple absolute font size selector.
Thank you for T-Bird. It saved me from W-Live.
Comment 39•11 years ago
|
||
Font changes occur on new and reply composition. Cut and Paste seems to exacerbate the problem, moving a sentence from the end of a paragraph to the middle or beginning.
Full message source attached in next reply.
Comment 40•11 years ago
|
||
This is the actual message source ... names hopefully changed to protect the innocent. Some of the header was stripped, as well.
Comment 41•11 years ago
|
||
Comment on attachment 8360888 [details]
BadFont.txt
Oh - bug remains in build 24.2.0 ... Unfortunately, it is now disrupting communications in a way that I now am looking for alternatives; even Outlook. Yuck.
Comment 42•11 years ago
|
||
Also - seems to be related to this panose-1 font (or perhaps the mso feature). Error console reports below. The panose-1 error comes up during auto-spell-check just before sending.
No - I don't have a Panose-1 font.
Timestamp: 1/15/2014 10:55:33 PM
Warning: Unknown descriptor 'panose-1' in @font-face rule. Skipped to next declaration.
Source File: mailbox:///C:/Users/Me/AppData/Roaming/Thunderbird/Profiles/xook8fm7.default/Mail/mail.me/Inbox?number=334168679
Line: 17, Column: 9
Source Code:
panose-1:2 11 6 4 3 5 4 4 2 4;}
Timestamp: 1/15/2014 10:55:33 PM
Warning: Unknown property 'mso-style-priority'. Declaration dropped.
Source File: mailbox:///C:/Users/Me/AppData/Roaming/Thunderbird/Profiles/xook8fm7.default/Mail/mail.me.net/Inbox?number=334168679
Line: 36, Column: 20
Source Code:
{mso-style-priority:99;
Comment 43•10 years ago
|
||
I have this problem in 24.2.0 and it is driving me potty. It makes TB seem amateur compared to Outlook which I used years ago. I will have to look for an alternative if this continues.
Comment 44•10 years ago
|
||
This is still happening as of 24.6.0 -
At times it seems to be also related to email that has been received from iPhones where the iPhone inserts characters not recognized by Windows (not true UNICODE). So an apostrophe ' or odd space shows up as a diamond ? symbol. Not sure where all the -C2=20 are coming from, but they look like malformed Unicode. Fonts change when similar characters appear in email.
and $50.=
=C2=20
I'm free all
Translates into:
$50.� I'm free all
Comment 45•10 years ago
|
||
In addition to the bugs listed at Comment 30 you can also add at the very least bug 677046.
Thunderbird changing fonts gets plenty of hits via Google:
https://www.google.com.au/search?q=thunderbird+changing+font+while+typing&ie=utf-8&oe=utf-8&aq=t&rls=org.mozilla:en-GB:official&client=firefox-a&channel=sb&gfe_rd=cr&ei=ScPqU7fLEIzN8gf8zYHICQ
For me all these editing issues with fonts sizes increasing mid-message and signatures not displaying and/or printing properly (fixed Bug report 919151) all commenced with an upgrade from TB17.0.8 to TB24.
Comment 47•8 years ago
|
||
There are bug reports along the lines of this one *all over the bugtracker* (including these ones: ##886146. 933409, 1209714).
Moreover, the functionality at issue - getting fonts to be consistent and user-controllable - is *basic*.
For those two reasons I submit that, unless Thunderbird wants to continue to lose market share, someone actually **fix this**, please. How hard can it be? I am almost ready to give up on Thunderbird - because, primarily, of this problem.
Updated•2 years ago
|
Severity: normal → S3
You need to log in
before you can comment on or make changes to this bug.
Description
•