Bug 138778 - bad ascii pango text editing and cursor positioning for CJKI
bad ascii pango text editing and cursor positioning for CJKI
Status: CLOSED RAWHIDE
Product: Red Hat Enterprise Linux 4
Classification: Red Hat
Component: firefox (Show other bugs)
4.0
All Linux
medium Severity medium
: ---
: ---
Assigned To: Christopher Aillon
Ben Levenson
: i18n
: 144347 (view as bug list)
Depends On: 149991
Blocks: 137149 155208
  Show dependency treegraph
 
Reported: 2004-11-10 21:58 EST by Leon Ho
Modified: 2007-11-30 17:07 EST (History)
8 users (show)

See Also:
Fixed In Version: firefox-1.0.3-1.4.1
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2005-05-05 02:28:35 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
a screenshot (97.56 KB, image/png)
2004-11-10 21:59 EST, Leon Ho
no flags Details
Another screenshot that the editing box with cursoring problem (65.48 KB, image/png)
2004-12-04 05:21 EST, Leon Ho
no flags Details
Reduced testcase (253 bytes, text/html)
2004-12-05 06:26 EST, Christopher Aillon
no flags Details
test code (1.20 KB, text/plain)
2004-12-08 04:37 EST, Akira TAGOH
no flags Details
patch (4.43 KB, patch)
2004-12-10 16:01 EST, Christopher Blizzard
no flags Details | Diff

  None (edit)
Description Leon Ho 2004-11-10 21:58:44 EST
Description of problem: 
cursor is not in correct position when text editing with pango. Hence 
there are no way for user to edit text correctly. 
 
Seems it happens with any text with "spaces" 
 
How reproducible: 
everytime 
 
Steps to Reproduce: 
1. LANG=ja_JP.UTF-8 MOZ_ENABLE_PANGO=1 mozilla 
2. go to one of the bugzilla bug 
3. Type "I love monkey" enter 
and 
4. Type "cursoring and text editing has the same problem" 
5. Backspace five times 
Actual results: 
- cursor is in the middle of "y" 
- Backspace does not clear "oblem" character on screen but actually 
it is deleted. 
 
Expected results: 
cursor should be at the end and should clear "oblem" correctly 
 
Additional info:
Comment 1 Leon Ho 2004-11-10 21:59:33 EST
Created attachment 106470 [details]
a screenshot
Comment 2 Jens Petersen 2004-11-16 07:14:31 EST
I confirmed that the same also happens for Korean, Chinese and Hindi
(I expect for all 5 Indic langs).
Comment 3 Jens Petersen 2004-11-24 00:43:59 EST
Still happens with firefox-1.0-4.EL4.
Comment 4 Leon Ho 2004-11-30 05:50:52 EST
With this it is quite difficult for non-english languages users to
edit anything in text editing box right now. Is it something that can
be looked into in RHEL4 RC timeframe?
Comment 5 Leon Ho 2004-11-30 06:21:15 EST
Look like it happens only if the line has spaces or tabs. If there
aren't the cursor positioned itself okay. Is it a good case for narrow
it down? 
Comment 7 dff 2004-12-03 22:59:59 EST
Notes from RHEL 4 RC blocker bug review meeting today: Doesn't meet criteria
outlined at
http://intranet.corp.redhat.com/ic/intranet/RHEL4RCBugFixCriteria.html, thus
moving from RHEL4RCBlocker to RHEL4RCShouldFix.
Comment 8 Leon Ho 2004-12-04 05:21:26 EST
Created attachment 107887 [details]
Another screenshot that the editing box with cursoring problem

Notice the edit box is pushed offf screen because of the font size.
Comment 9 Leon Ho 2004-12-04 05:21:37 EST
Created attachment 107888 [details]
Another screenshot that the editing box with cursoring problem

Notice the edit box is pushed offf screen because of the font size.
Comment 10 Christopher Aillon 2004-12-05 06:26:04 EST
Created attachment 107911 [details]
Reduced testcase
Comment 11 Christopher Aillon 2004-12-05 06:55:34 EST
could this be caused by getting passed strings that aren't properly
terminated?


#0  nsFontMetricsPango::DrawString (this=0x9a59ff8, 
    aString=0xfee26cb0 "cursoring and typing text in here have the
same problem���4,��o�\200m�Xo�\030��o���\200m�", aLength=55,
aX=161849336, aY=161849336, 
    aSpacing=0x0, aContext=0x92ad6e0, aSurface=0x9c62250) at
nsFontMetricsPango.cpp:730
#1  0xf5c37005 in nsRenderingContextGTK::DrawString (this=0x92ad6e0, 
    aString=0xfee26cb0 "cursoring and typing text in here have the
same problem���4,��o�\200m�Xo�\030��o���\200m�", aLength=55, aX=0,
aY=240, aSpacing=0x0)
    at nsRenderingContextGTK.cpp:1313
#2  0xf55f16e9 in nsTextFrame::PaintAsciiText (this=0x9a58dd8,
aPresContext=0x99b9ff8, aRenderingContext=@0x92ad6e0,
aStyleContext=0x9becd50, aTextStyle=@0xfee271f0, dx=0, 
    dy=0) at nsTextFrame.cpp:3297
#3  0xf55ecf81 in nsTextFrame::Paint (this=0x9a58dd8,
aPresContext=0x99b9ff8, aRenderingContext=@0x92ad6e0,
aDirtyRect=@0xfee27290, aWhichLayer=eFramePaintLayer_Overlay, 
    aFlags=0) at nsTextFrame.cpp:1460
#4  0xf557cddd in nsContainerFrame::PaintChild (this=0x9a681ec,
aPresContext=0x99b9ff8, aRenderingContext=@0x92ad6e0,
aDirtyRect=@0xfee277e0, aFrame=0x9a58dd8, 
    aWhichLayer=eFramePaintLayer_Overlay, aFlags=0) at
nsContainerFrame.cpp:303
#5  0xf5563d93 in nsBlockFrame::PaintChild (this=0x9a681ec,
aPresContext=0x99b9ff8, aRenderingContext=@0x92ad6e0,
aDirtyRect=@0xfee277e0, aFrame=0x9a58dd8, 
    aWhichLayer=eFramePaintLayer_Overlay, aFlags=0) at nsBlockFrame.h:242
#6  0xf556fb40 in PaintLine (aLineArea=@0xfee27570,
aDirtyRect=@0xfee277e0, aLine=@0x1, aDepth=161844696,
aDrawnLines=@0xfee273cc, aPresContext=0x99b9ff8, 
    aRenderingContext=@0x92ad6e0,
aWhichLayer=eFramePaintLayer_Overlay, aFrame=0x9a681ec) at
nsBlockFrame.cpp:5414
#7  0xf556f918 in nsBlockFrame::PaintChildren (this=0x9a681ec,
aPresContext=0x99b9ff8, aRenderingContext=@0x92ad6e0,
aDirtyRect=@0xfee277e0, 
    aWhichLayer=eFramePaintLayer_Overlay, aFlags=0) at
nsBlockFrame.cpp:5483
#8  0xf55996cf in nsHTMLContainerFrame::PaintDecorationsAndChildren
(this=0x9a681ec, aPresContext=0x99b9ff8, aRenderingContext=@0x92ad6e0,
aDirtyRect=@0xfee277e0, 
    aWhichLayer=eFramePaintLayer_Overlay, aIsBlock=1, aFlags=0) at
nsHTMLContainerFrame.cpp:138
#9  0xf556f51e in nsBlockFrame::Paint (this=0x9a681ec,
aPresContext=0x99b9ff8, aRenderingContext=@0x92ad6e0,
aDirtyRect=@0xfee277e0, aWhichLayer=eFramePaintLayer_Overlay, 
    aFlags=0) at nsBlockFrame.cpp:5306
#10 0xf55da8a8 in PresShell::Paint (this=0x999e890, aView=0x9bee360,
aRenderingContext=@0x92ad6e0, aDirtyRect=@0xfee277e0) at
nsPresShell.cpp:5560
Comment 12 Christopher Aillon 2004-12-05 21:21:42 EST
Actually, no, ignore my previous comment: it's fine in this context since we
pass in a length and do the right thing with it.  The problem is likely
somewhere in layout not adding the right padding or something around the
characters.  Note that this problem also exists not only with spaces but with
punctuations, iow periods, commas, apostrophes, etc.

Changing nsFontMetricsPango::mSpaceWidth to be mSpaceWidth * 5 / 4; seems to
"fix" this problem, but I suspect it causes more problems.  In the textarea, we
are calculating spaces 20% low and maybe 22% for punctuation.  Still haven't
tracked down the root cause yet.  Will look more tomorrow.
Comment 13 Akira TAGOH 2004-12-08 04:37:47 EST
Created attachment 108097 [details]
test code

I just wrote a simple testing code to get the glyph width from Pango. it looks
like a space doesn't necessarily have a fixed width. so if the strings contains
any space characters, mozilla needs to calculate the width with space.	Here is
the result with this test code:
$ ./t Sans
Font: Sans
pango_layout_get_size("a") => width: 9
pango_layout_get_size("b") => width: 9
pango_layout_get_size(" ") => width: 8
pango_layout_get_size(" a") => width: 13
pango_layout_get_size(" ab") => width: 22
pango_layout_get_size("ab") => width: 18
$ ./t Serif
Font: Serif
pango_layout_get_size("a") => width: 7
pango_layout_get_size("b") => width: 8
pango_layout_get_size(" ") => width: 8
pango_layout_get_size(" a") => width: 11
pango_layout_get_size(" ab") => width: 19
pango_layout_get_size("ab") => width: 15
$ ./t Monospace
Font: Monospace
pango_layout_get_size("a") => width: 10
pango_layout_get_size("b") => width: 10
pango_layout_get_size(" ") => width: 8
pango_layout_get_size(" a") => width: 20
pango_layout_get_size(" ab") => width: 30
pango_layout_get_size("ab") => width: 20
Comment 14 Christopher Blizzard 2004-12-10 16:01:44 EST
Created attachment 108355 [details]
patch

This patch should "fix" the problems.  It fixes all spaces to the same width
since mozilla's layout engine assumes that this is the case.
Comment 16 Jens Petersen 2004-12-12 23:44:47 EST
Great with this -11-EL4 seems to fix the problem for me. :-)
Comment 18 Harald Hoyer 2004-12-16 08:50:53 EST
Cursor navigation is broken also!! Pressing <left> sometimes skips
several chars...
$ rpm -q firefox
firefox-1.0-12.EL4
$ echo $LANG
de_DE.UTF-8
Comment 19 Christopher Blizzard 2004-12-16 11:11:22 EST
Do you have a good small test case for german text?  (If you're using
de_DE, you're not using pango.)
Comment 20 Harald Hoyer 2004-12-16 11:19:24 EST
well typing in this comment textarea right now and pressing the <left>
cursor key shows the symptom immediately :-( very annoying...
Comment 21 Christopher Blizzard 2004-12-16 11:28:26 EST
Oh, dear.  Crap.  The non-pango case appears to be broken.
Comment 22 Christopher Blizzard 2004-12-16 11:33:37 EST
Doesn't happen in my tip build.  Only seems to happen with the firefox
build that we have.  Looking into it.
Comment 24 Christopher Blizzard 2004-12-16 13:20:50 EST
OK, should be fixed in 13.EL4.
Comment 25 Harald Hoyer 2004-12-17 09:09:20 EST
works :) Thx!
Comment 26 Christopher Aillon 2005-01-06 21:00:03 EST
*** Bug 144347 has been marked as a duplicate of this bug. ***
Comment 27 Jay Turner 2005-01-14 08:18:29 EST
Closing out based on feedback above.
Comment 28 Jens Petersen 2005-02-07 22:01:45 EST
Unfortunately I'm sometimes still seeing problems with both
EL4 firefox, and fc4 firefox and thunderbird.

Re-opening fyi: more details to come.
Comment 29 Jay Turner 2005-02-10 08:26:45 EST
I too was still seeing it with GA firefox (1.0-12.EL4) but have since updated to
1.0-13.EL4 and am no longer seeing the problem.  Jens, any chance the new
version fixes the issues you're seeing?  I'm pulling this from the RCShouldFix
list and putting it into NEEDINFO to collect details on if Jens is still seeing
problems.
Comment 31 Jens Petersen 2005-03-01 06:23:36 EST
It is better in newer builds, but see also bug 149991 for a related 
case affecting numeric text.
Comment 32 Jens Petersen 2005-03-11 01:47:57 EST
Apart from bug 149991 (pango issue with input of numbers and punctuation)
input seems to be better now, testing with current rawhide
(firefox-1.0.1-5).
Comment 33 Christopher Aillon 2005-05-03 16:21:38 EDT
This got fixed eons ago in the 0day errata, moving to MODIFIED.
Comment 34 Lawrence Lim 2005-05-05 02:28:35 EDT
Tested with firefox-1.0.3-1.4.1, CJKI input looks good.


Thanks.

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