Bad caret placement after splitting nested inline.

RESOLVED DUPLICATE of bug 84645

Status

()

Core
Selection
P2
normal
RESOLVED DUPLICATE of bug 84645
17 years ago
17 years ago

People

(Reporter: kinmoz, Assigned: Chris Waterson)

Tracking

Trunk
mozilla0.9.5
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(2 attachments)

(Reporter)

Description

17 years ago
If I load the following HTML into composer:

<html><body><i>Line 1<br>Line 2 <b>bold text</b></i></body></html>

and follow these steps, I get bad caret placement which seems to be related to 
the fact that there are nested inline styles:

1. Load sample file in composer.
2. Click after "bold text" to place the caret at the end of the line.
3. Hit the return key.
4. Type a word. (Notice that what you typed is bold)
5. Select the word you typed.
6. Hit the bold button on the tool bar to unbold the selection.

Now at this point, if you place your caret after the word you just typed, and 
hit the return key, the caret will fly up to just before the 'b' in "bold text"! 
This seems to be a caret rendering problem, since the collapsed selection *is* 
in the correct place.

Also if you try clicking on "bold text" you'll notice that the caret renders 
above the line!
(Reporter)

Updated

17 years ago
Status: NEW → ASSIGNED
Priority: -- → P3
Target Milestone: --- → mozilla0.9.3
(Reporter)

Comment 1

17 years ago
Created attachment 42093 [details]
Test case.
(Reporter)

Comment 2

17 years ago
This looks like a layout reflow problem. I verified that the content model is 
actually correct, and that the selection ranges are being set properly.

After step 6 above, the content model looks something like this:

  <i>Line 1<br>Line 2<b>bold text<br></b>NewWord<b><br></b>

The problem seems to be that nsCaret::GetViewForRendering() is getting back a 
different y offset from the call to caretFrame->GetOffsetFromView(), where 
caretFrame is the TextFrame containing "bold text", because the <i> inline frame 
has a bad y coordinate for it's origin.

Handing this over to waterson, since this may be related to the nested inline 
frame incremental-reflow problem seen in bug 90521.

FYI, I could probably whip up a JS test case that causes the same problem in the 
browser, though you wouldn't be able to tell since there is no caret in the 
browser ... but it might be helpful to see the ordering of the DOM calls that 
triggers this bug.
Assignee: kin → waterson
Status: ASSIGNED → NEW
(Assignee)

Updated

17 years ago
Status: NEW → ASSIGNED
Priority: P3 → P2
(Reporter)

Comment 3

17 years ago
Created attachment 42630 [details]
JS Test case.
(Reporter)

Comment 4

17 years ago
I just attatched a JS test case, for use in the browser, which shows the steps 
that the editor is using. You can see the offset problem by drag selecting 
over the "bold text" after pressing the "Unbold" button.
(Assignee)

Updated

17 years ago
Target Milestone: mozilla0.9.3 → mozilla0.9.4
(Assignee)

Updated

17 years ago
Target Milestone: mozilla0.9.4 → mozilla0.9.5
(Assignee)

Comment 5

17 years ago
This is probably another dup of 84645. It now WORKSFORME. (kin, please sanity
check me here! I tried both the composer test case and the JS test case, and
they appear to be fine...thanks!)

*** This bug has been marked as a duplicate of 84645 ***
Status: ASSIGNED → RESOLVED
Last Resolved: 17 years ago
Resolution: --- → DUPLICATE
(Reporter)

Comment 6

17 years ago
*** Bug 82161 has been marked as a duplicate of this bug. ***
You need to log in before you can comment on or make changes to this bug.