Closed Bug 138608 Opened 23 years ago Closed 23 years ago

caret jumps to front of text after hitting return

Categories

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

Product:
Core
Component:
DOM: Editor
Type:
defect

Tracking

()

Status:
VERIFIED FIXED
Milestone:
mozilla1.0.1

People

(Reporter: sujay, Assigned: mozeditor)

References

Details

(Keywords: regression, topembed, Whiteboard: [adt2 RTM] EDITORBASE+ [ETA 06/28])

using 4/19 trunk and branch 1) launch netscape 2) launch composer 3) enter some text(whether you hit space or not after this does not matter) 4) hit Bold 5) hit carriage return observe where the caret is...its at the beginning of the first line. it should be at the begin of 2nd line. but when you start typing text it jumps back down to where its supposed to be.
Keywords: nsbeta1, regression
Whiteboard: EDITORBASE
if you don't hit Bold then this problem does not occur.
Keywords: nsbeta1 → nsbeta1+
Whiteboard: EDITORBASE → EDITORBASE+
Target Milestone: --- → mozilla1.0
This is only reproducible once after you open composer. You need to close it and open it to reproduce it again. This happens with bold/italic/font color/size, etc. probably anything that adds formatting.
We're probably not reflowing the new <br>. I'll take a look.
Assignee: mjudge → kin
Priority: -- → P3
Turns out this isn't a layout problem per se ... the problem seems to be due to the fact that we're not stripping out a bogus empty text node we are adding when one of the SplitNode*() methods get called. This leaves the content looking something like: <body><b><br>|[]</b></body> where the '[]' is the empty text node and the '|' is the position of the caret/selection after hitting return. I have a quick hack in my tree that fixes/verifies that this is indeed the problem. After talking to jfrancis, I think we're going to have to do something during the post-processing stage to strip out this empty text node. Note that this empty text node can also be left in the content tree when we substitute inserting images and hrules instead of hitting return.
Status: NEW → ASSIGNED
Handing off to jfrancis at his request.
Assignee: kin → jfrancis
Status: ASSIGNED → NEW
Whiteboard: EDITORBASE+ → [adt2]EDITORBASE+
any status on this bug ?
Component: Editor: Composer → Editor: Core
status is it is fixed by an earlier checkin
Status: NEW → RESOLVED
Closed: 23 years ago
Resolution: --- → FIXED
verified in 5/20 trunk build.
Status: RESOLVED → VERIFIED
jfrancis: Is this fixed on the 1.0.0 branch by the earlier checkin?
Keywords: adt1.0.1
joe - can you pls addres Kevin's question? we'd like to know, if this patch needs to be checked in to the 1.0 branch? thanks!
Keywords: approval, mozilla1.0.1
Whiteboard: [adt2]EDITORBASE+ → [adt2] EDITORBASE+
Target Milestone: mozilla1.0 → mozilla1.0.1
No, this is not fixed on the branch.
Whiteboard: [adt2] EDITORBASE+ → [adt2 RTM] EDITORBASE+ [ETA 06/28]
Removing nsbeta1+, adt1.0.1, mozilla1.0.1. The fix is too risky for the 1.0 branch.
Keywords: adt1.0.1, approval, mozilla1.0.1, nsbeta1+ → nsbeta1-
batch: adding topembed per Gecko2 document http://rocknroll.mcom.com/users/marek/publish/Gecko/Gecko2Tasks.html
Keywords: topembed
Blocks: grouper
You need to log in before you can comment on or make changes to this bug.