Closed Bug 21029 Opened 25 years ago Closed 25 years ago

Caret get's wrong offset when parent not a text node

Categories

(Core :: DOM: Selection, defect, P3)

defect

Tracking

()

VERIFIED FIXED

People

(Reporter: mozeditor, Assigned: kinmoz)

References

Details

To see this bug, you will first have to comment out a line of code that hides the
bug.  Comment out the call to AdjustSelection() that is in
nsHTMLEditRules::AfterEdit().

Once that's done, bring up Composer with the test page.  Put your caret right in
front of "Here is an acute..." (right before the "H").  Backspace once.  Note
that the caret now displays as being "Her^e is an acute...".  But the selection
is acutally before the "Here".  If you type, characters will appear before the
"Here"
Status: NEW → ASSIGNED
Target Milestone: M13
Accepting bug. Marking M13.
The problem is that nsCaret::SetupDrawingFrameAndOffset() assumes that it can
use the selection's node offset with the frame it gets from
nsRangeList::GetFrameForNodeOffset().

Here's why it can't do that. Suppose you have following:

    <p>This is p1</p>
    <p>This is p2</p>

If you place the cursor before the "This is p2" and hit the backspace key, the
rules code will join the two paragraphs and leave the caret right after the br
(node == <p>, offset == 2):

    <p>This is p1 <br>This is p2</p>

When GetFrameForNodeOffset() is called for this node/offset, it gets back the
frame the text node containing "This is p2" because it wants us to snap the
caret to the beginning of the line that "This is p2" is on.

So when the caret goes to draw itself, it uses the text frame to call
nsIFrame::GetPointFromOffset() and it uses 2 as the offset, which is incorrect.
That's why the cursor draws in the wrong place.

I think we might have to modify GetFrameForNodeOffset() to also return an offset
into the frame.
Blocks: 21545
Status: ASSIGNED → RESOLVED
Closed: 25 years ago
Resolution: --- → FIXED
mozilla/layout/base/public/nsIFrameSelection.h    revision 1.25
      -
Added aReturnOffset arg to GetFrameForNodeOffset().


mozilla/layout/base/src/nsCaret.cpp    revision 1.40
      - mLastContentOffset
now gets it's value from the offset
        returned by GetFrameForNodeOffset().

    mozilla/layout/base/src/nsRangeList.cpp    revision 1.171
      -
GetFrameForNodeOffset() now returns an offset to be used
        with the result
frame.


r= mjudge@netscape.com,jfrancis@netscape.com
Joe, this bug is unfortunately not possible for me to verify. Could you please
confirm that it's fixed and, if so, mark it as verified? Thanks!
Status: RESOLVED → VERIFIED
verified by joe
You need to log in before you can comment on or make changes to this bug.