Bug 149991 - [CJK pango] digits and punctuation in textbox give bad eol rendering and cursor placement
[CJK pango] digits and punctuation in textbox give bad eol rendering and curs...
Product: Fedora
Classification: Fedora
Component: firefox (Show other bugs)
All Linux
high Severity high
: ---
: ---
Assigned To: Gecko Maintainer
Fedora Extras Quality Assurance
: Reopened
Depends On: 129541
Blocks: 138778 FIREFOX_PANGO FC5Update 211660
  Show dependency treegraph
Reported: 2005-03-01 06:20 EST by Jens Petersen
Modified: 2018-04-11 08:36 EDT (History)
9 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2008-02-22 01:16:32 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
bad-moz-pango-tweak.patch (570 bytes, patch)
2006-01-31 20:13 EST, Jens Petersen
no flags Details | Diff

External Trackers
Tracker ID Priority Status Summary Last Updated
Mozilla Foundation 306404 None None None Never

  None (edit)
Description Jens Petersen 2005-03-01 06:20:55 EST
Description of problem:
When running pango firefox in a CJK locale, pasting
numbers into a editbox makes the cursor movement
behave strangely. Also highlighting numeric
characters changes their size.

How reproducible:

Steps to Reproduce:
1. $ LANG=ja_JP.UTF-8 firefox
2. Highlight a number 
3. Click on a line with just a number in it.
4. Paste a number into an edit box and keep typing some words.
Actual results:
2. The glyphs change size.
3. The cursor goes to the beginning of the line.
4. The number changes size when text is added after it
   and the cursor falls behind the test.  The last character
   on the line is often not rendered completely.

Expected results:
2. no size change
3. the cursor is be at the end of the number
4. editting, cursor movement and rendering to work correctly.

Additional info:
This is like 138778 but for numeric text.
Comment 1 Jens Petersen 2005-03-10 21:45:11 EST
Getting highly annoying in both firefox and thunderbird:
raising priority.
Comment 2 Jens Petersen 2005-03-11 01:24:17 EST
The same is also true for punctuation input into editboxes.

Comment 3 Jens Petersen 2005-04-07 20:59:35 EDT
Also the End key brings one to the start of a line if it has only numbers
or punctuation in it.

Note also how the font of the numbers and/or punctuation changes after
input some alphabet after them.
Comment 4 Christopher Blizzard 2005-04-25 14:05:33 EDT
Should be fixed in firefox 1.0.3-1.3.1.
Comment 5 Jens Petersen 2005-04-25 22:34:22 EDT
Unfortunately not.
Comment 6 Jens Petersen 2005-04-25 23:00:12 EDT
Ok, I should clarify the report a little, since it was pointed out
to me that a part of the problem is in pango:

In "LANG=ja_JP.UTF-8 gedit" for example if one inputs some numbers and/or
punctuation chars at the beginning of a line and then appends other text
the change of font of the numbers/punctuations also happens.
However cursor placement and the end of line is fine.

Not so in firefox/thunderbird: the cursor is placed wrongly and
the last character on the line is badly misrendered.
This is the issue that needs to be fixed still in moz pango.
Scrolling the line in question off screen and back into view shows
the last character correctly rendered, however cursor placement remains off.
Comment 7 Lawrence Lim 2005-05-05 03:09:43 EDT
Bug still exist firefox-1.0.3-4 in dist-FC4. However, I noticed that for
firefox-1.0.3-1.4.1 in EL4, I could not reproduce this bug. 
Comment 8 Jens Petersen 2005-05-06 21:45:12 EDT
Appears to be fixed in mozilla-1.7.7-3 too. :)

If this could be fixed next in FC4 firefox and thunderbird that would be great.
Comment 9 Warren Togami 2005-05-10 01:31:42 EDT
Regarding comment #7, keep in mind that EL4 pango is disabled for all languages
except Indic, while FC4 pango is enabled on all languages.  llch indicated that
the EL4 testing was done in ja_JP.UTF-8, which would be pango disabled.

If this is the case, then this bug is not fixed for the pango case.  In FC4 you
can use MOZ_DISABLE_PANGO=1 to test if this is the case.  Please verify.
Comment 10 Jens Petersen 2005-05-10 02:19:35 EDT
Ooops, scratch comment 8 - mozilla doesn't seem to have pango enabled... doh.
Comment 11 Lawrence Lim 2005-05-10 02:41:15 EDT
My bad. It slipped my mind that we have special case for EL4. Thanks to warren
for pointing out.

Tested with firefox-1.0.3-4 (with pango enabled), the bug still exist. However,
if I run without pango, everything is good.

Comment 13 Jens Petersen 2005-08-30 00:56:10 EDT
Has this bug been reported upstream?
Comment 14 Jens Petersen 2005-08-30 03:55:42 EDT
I filed <https://bugzilla.mozilla.org/show_bug.cgi?id=306404>.
Comment 15 Jens Petersen 2005-09-27 09:26:10 EDT
This still occurs with Deer Park fwiw.
Comment 16 Leon Ho 2006-01-16 20:31:01 EST
Firefox (1.5) is still having problem on this. This bug is very obvious and
serious when it has these character insert in the sentence ( ) .

For instance, for this comment i cannot complete it in the text box directly
because of this problem.
Comment 24 Jens Petersen 2006-01-31 20:13:35 EST
Created attachment 123944 [details]

This is just a completely naive patch but points at the code/file in question
at least: it fixes the rendering in the textboxes but then breaks rendering
of numbers and punctuation elsewhere. ;-)
Comment 25 Tim Mayberry 2006-02-08 01:53:51 EST
FireFox asdlkfj tyrtrtrerterterterdfgsdfg2233443344234234 12121212
Comment 26 Tim Mayberry 2006-02-08 02:00:23 EST
Sorry about that last comment, it was unintentional.
Comment 27 Warren Togami 2006-03-06 10:36:28 EST
Moving to FC6 and FC5Update because there is no visible progress in this report
and we are out of time.
Comment 28 Tim Mayberry 2006-03-24 02:13:59 EST
Sorry for taking so long to respond to this bug, I'm not familiar with firefox
or pango but after a little debugging I think I know what the problem is, or at
least part of it.

The font that is selected by pango/firefox for rendering numeric characters in
that locale is different from the font selected for rendering latin characters
which is easy to see if you type in a string of characters such as "1111a" as
the font will change when you type the 'a' character.

The nsTextFrame class as part of the text layout process calls
nsTextFrame::MeasureText which breaks up the string contained in the
layout(firefox uses one layout per line as I understand it) into white space
delineated substrings/words and then calls nsFontMetricsPango::GetTextDimensions
on each substring/word. nsFontMetricsPango::GetTextDimensions gets the text
dimensions for each substring by creating a new layout, setting the text to the
substring and getting the total dimensions/extents from that. The problem is
that when it does this on a string such as "1 12 123 1234 ab" it looks as if the
font used in each layout is dependant on the code points of the characters in
each substring, so in that case the width for the first four substrings will be
calculated incorrectly because the width of the font used for numeric characters
is narrower in than that font used for the latin characters. As the original or
displayed layout uses the wider latin font it messes up the cursor position and
creates drawing/expose errors in the text area.

If someone more familiar with pango would like to comment, I've really only just
started on this problem so it would be good to know that I'm on the right track.
Comment 29 Tim Mayberry 2006-03-25 09:04:47 EST
I just noticed bug 132527 and comment #11 by Owen Taylor seems very similar to
the behaviour I described in comment 28, just making a note of it for future
Comment 30 Jens Petersen 2006-08-13 23:39:01 EDT
I can't reproduce this in the context of bugzilla.redhat.com anyway
anymore with current fc6 firefox.

Still happens on firefox- though.
Comment 31 Akira TAGOH 2006-08-14 03:39:34 EDT
also still happens on firefox- but not when any bitmaps font are
used for rendering. it sounds like this issue is caused by another library, such
as pango, cairo and freetype.

On FC5,
$ rpm -q pango cairo freetype firefox

On FC6,
$ rpm -q pango cairo freetype firefox
Comment 32 Leon Ho 2006-08-14 20:48:43 EDT
I think the debug info in comment #28 is valid, if pango changes the glyph usage
when editing, hence it will change its glyph metric/layout during editing.

Tim, did you have any draft patch?

Reassigning from Tim to Tagoh-san.
Comment 33 Akira TAGOH 2006-08-14 22:48:06 EDT
changed the version to fc5, since this no longer appears on the latest firefox
and libraries sets.
Comment 34 Jens Petersen 2006-10-25 04:27:04 EDT
Unfortunately I still see the problem now again with FC6 final.
Comment 35 Matěj Cepl 2007-05-02 16:57:19 EDT
Is this still reproducable with firefox-
Comment 36 Jens Petersen 2007-05-02 20:20:03 EDT
Yes and in F7. :-/

It is easy to reproduce if you run it in a CJK locale.
Comment 37 Matěj Cepl 2007-12-10 04:22:40 EST
Fedora Core 6 is no longer supported, could you please reproduce this with the
updated version of the currently supported distribution (Fedora 7, 8, or
Rawhide)? If this issue turns out to still be reproducible, please let us know
in this bug report. If after a month's time we have not heard back from you, we
will have to close this bug as CANTFIX.

Setting status to NEEDINFO, and awaiting information from the reporter.

[This is mass-filed message to all open Fedora Core 6 bugs related to Xorg or
Gecko. If you see any other reason, why this bug shouldn't be closed, please,
comment on it here.]
Comment 38 Matěj Cepl 2008-01-15 09:39:39 EST
Since there are insufficient details provided in this report for us to
investigate the issue further, and we have not received feedback to the
information we have requested above, we will assume the problem was not
reproducible, or has been fixed in one of the updates we have released for the
reporter's distribution.

Users who have experienced this problem are encouraged to upgrade to the latest
update of their distribution, and if this issue turns out to still be
reproducible in the latest update, please reopen this bug with additional


{This is mass-closing of all obsolete bugs; if this bug was in your opinion
closed by mistake, please, reopen it with additional information; thanks a lot
and I am sorry for bothering you in such case.}
Comment 39 Behdad Esfahbod 2008-01-15 14:32:44 EST
It was noted that this happens in F7 still, possibly F8 too.
Comment 40 Matěj Cepl 2008-02-08 15:42:35 EST
Since this bugzilla report was filed, we have seriously upgraded Gecko-related
packages, which may have resolved this issue. Users who have experienced this
problem are encouraged to upgrade their system to the latest version of their
distribution available.

Please, confirm to us that this bug is reproducible on the latest upgrade of the
supported distribution (that's RHEL, or Fedora 7, 8, and Rawhide).

Setting the bug to NEEDINFO. If I won't get confirmation of reproducability in
30 days, the bug will be closed as INSUFFICIENT_DATA.

[This is mass-changing of bugs which seem to be too old and irrelevant anymore;
we are sorry, if this bug should not be incldued.]
Comment 41 Matěj Cepl 2008-02-21 17:34:56 EST
At this point, we're going to only be taking security fixes and major stability
fixes into this release of Fedora.  However, we still want to ensure the bug is
fixed in the next version.  We'd appreciate if you could test Firefox 3,
available at http://www.mozilla.com/en-US/firefox/all-beta.html or now shipping
as the default in Fedora rawhide and provide feedback as to whether it still
exists so we can file a ticket upstream to try to fix it in Firefox 3 before it
is released.
Comment 42 Matěj Cepl 2008-02-21 17:36:17 EST
At this point, we're going to only be taking security fixes and major stability
fixes into this release of Fedora.  However, we still want to ensure the bug is
fixed in the next version.  We'd appreciate if you could test Firefox 3,
available at http://www.mozilla.com/en-US/firefox/all-beta.html or now shipping
as the default in Fedora rawhide and provide feedback as to whether it still
exists so we can file a ticket upstream to try to fix it in Firefox 3 before it
is released.
Comment 43 Jens Petersen 2008-02-22 00:09:57 EST
Yes this is fixed in Firefox 3.

Moving bug to Fedora 8.
Comment 44 Christopher Aillon 2008-02-22 01:16:32 EST
Going to resolve this out as NEXTRELEASE then, since it'll be fixed in F9.

Note You need to log in before you can comment on or make changes to this bug.