Closed
Bug 90528
Opened 23 years ago
Closed 23 years ago
Bad caret placement after splitting nested inline.
Categories
(Core :: DOM: Selection, defect, P2)
Core
DOM: Selection
Tracking
()
mozilla0.9.5
People
(Reporter: kinmoz, Assigned: waterson)
References
Details
Attachments
(2 files)
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!
Status: NEW → ASSIGNED
Priority: -- → P3
Target Milestone: --- → mozilla0.9.3
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•23 years ago
|
Status: NEW → ASSIGNED
Priority: P3 → P2
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•23 years ago
|
Target Milestone: mozilla0.9.3 → mozilla0.9.4
|
|
Assignee | |
Updated•23 years ago
|
Target Milestone: mozilla0.9.4 → mozilla0.9.5
|
|
Assignee | |
Comment 5•23 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
Closed: 23 years ago
Resolution: --- → DUPLICATE
*** 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.
Description
•