107905 - caret position incorrect (overlap last letter)

Status: VERIFIED FIXED

(Core :: Layout, defect)

Description

[Cliff Scott]

From Bugzilla Helper:
User-Agent: Mozilla/5.0 (OS/2; U; Warp 4.5; en-US; rv:0.9.5) Gecko/20011016
BuildID:    2001101616

When entering typed text in a field the Cursor sits on top of the last letter
typed and not at the position for the next letter to be typed. Depending on the
letter it  can appear in front of the last letter. This makes writing and
editing very strange and contribues to errors.

This happens anywhere text is entered. Netscape does not have this problem.

Reproducible: Always
Steps to Reproduce:
1.Type text anywhere.
2. Note the position of the cursor as you type.
3.

Comment 1

[Mike Kaply [:mkaply]]

Javier was working on this

Comment 2

[Kathleen :Brade]

This is a duplicate of another bug... probably a bug on mjudge's list...

Comment 3

[jhp (no longer active)]

The caret is getting the offset for the last letter wrong.  Here are 
some values I found from putting a printf in DrawCaret():

            good case [n-1]      bad case [n]
pixels           462                 470
pixels*12       5544                5640
caret pos       5544                5604

The good case is with the caret behind the second to last letter.  The 
bad case is with caret drawn after last letter, where it overlaps on 
long sentences.  The mPixelToTwips value is 12.  

The last letter will also get cutoff partially sometimes.  Maybe there 
is a clip rect for the text line that is being calculated incorrectly.  
Still looking...

Comment 4

[Kathleen :Brade]

I think this bug is a duplicate of bug 98564

Comment 5

[kinmoz]

Yes, this is a dup of 98564, and the overlapping is on purpose to avoid the
plethora of caret redraw problems we had at the time. See nsCaret::DrawCaret()
where there is the following comment:

    // Avoid view redraw problems by making sure the
    // caret doesn't hang outside the right edge of
    // the frame. This ensures that the caret gets
    // erased properly if the frame's right edge gets
    // invalidated.

*** This bug has been marked as a duplicate of 98564 ***

Comment 6

[jhp (no longer active)]

No, this is not a dup.  This is actually an OS/2 bug.  The situation 
on OS/2 is much worse than what is being discussed in bug 98564;  on 
OS/2, the caret overlaps the last letter more and more as the sentence 
gets longer.  The problem is due to how nsTextFrame measures the text 
length.  At the moment, OS/2 takes the same path as windows in the 
function MeasureText(), wherein we measure word by word if the text is 
PreFormatted (monospace) text.  However, this will not work if the 
monospace font selected is a non-bitmap font.

There is a problem with the TrueType rendering engine on OS/2, where 
it doesn't render letters on pixel boundaries.  This leads to many 
indiscrepencies (such as jiggling text when highlighting it), since 
the length of one whole sentence isn't always equal to the sum of the 
length of its words, as computed by Mozilla.  This is not a problem 
with bitmap fonts since they always fall on pixel boundaries.

My fix then was to remove the check for mPreformatted on line 4398 of 
nsTextFrame.cpp for OS/2.  After applying this fix, I no longer see 
this OS/2 specific issue in the new message editor or in bugzilla text 
boxes, but I do now see the problem discussed in bug 98564.

Comment 7

[jhp (no longer active)]

Attachment: patch

Comment 8

[Mike Kaply [:mkaply]]

Comment on attachment 59723 [details] [diff] [review]
patch

r=mkaply

Nice Catch

Comment 9

[Marc Attinasi]

Comment on attachment 59723 [details] [diff] [review]
patch

sr=attinasi

Comment 10

[Mike Kaply [:mkaply]]

Fix checked in

Comment 11

[Mike Kaply [:mkaply]]

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

Comment 12

[Jessica Blanco]

Verified -fixed