Bug 138778

Created attachment 106470 [details]
a screenshot

I confirmed that the same also happens for Korean, Chinese and Hindi
(I expect for all 5 Indic langs).

Still happens with firefox-1.0-4.EL4.

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?

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? 

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.

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.

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.

Created attachment 107911 [details]
Reduced testcase

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

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.

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

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.

Great with this -11-EL4 seems to fix the problem for me. :-)

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

Do you have a good small test case for german text?  (If you're using
de_DE, you're not using pango.)

well typing in this comment textarea right now and pressing the <left>
cursor key shows the symptom immediately :-( very annoying...

Oh, dear.  Crap.  The non-pango case appears to be broken.

Doesn't happen in my tip build.  Only seems to happen with the firefox
build that we have.  Looking into it.

OK, should be fixed in 13.EL4.

works :) Thx!

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

Closing out based on feedback above.

Unfortunately I'm sometimes still seeing problems with both
EL4 firefox, and fc4 firefox and thunderbird.

Re-opening fyi: more details to come.

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.

It is better in newer builds, but see also bug 149991 for a related 
case affecting numeric text.

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).

This got fixed eons ago in the 0day errata, moving to MODIFIED.

Tested with firefox-1.0.3-1.4.1, CJKI input looks good.


Thanks.