Closed
Bug 61232
Opened 24 years ago
Closed 23 years ago
caret comes back to previous line after selecting Paragraph Style
Categories
(Core :: DOM: Editor, defect, P2)
Tracking
()
VERIFIED
FIXED
mozilla0.9.2
People
(Reporter: sborusu, Assigned: mozeditor)
References
Details
(Whiteboard: [caret][QAHP] fix in hand; need a=)
Attachments
(2 files)
512 bytes,
patch
|
Details | Diff | Splinter Review | |
4.53 KB,
patch
|
Details | Diff | Splinter Review |
From Bugzilla Helper: User-Agent: Mozilla/4.0 (compatible; MSIE 5.0; Windows NT; DigExt) BuildID: Netscape 6 (Mozilla/5.0 20001108) I typed some text in new composer page and pressed enter key and selected new Paragraph style. Then cursor come back to the previous line. Reproducible: Always Steps to Reproduce: 1. Open a new composer window. 2. Type some text. 3. Press "Enter" key. 4. Select Format->Paragraph->Heading2 Actual Results: Cursor come back to previous line. (Then press enter again. Type text. It doesn't have Heading2 style as selected before) Expected Results: It should be in the new line only.
Comment 1•24 years ago
|
||
assigning to jfrancis
Assignee: beppe → jfrancis
Status: UNCONFIRMED → NEW
Ever confirmed: true
Assignee | ||
Comment 2•24 years ago
|
||
accepting bug; moz0.8
Status: NEW → ASSIGNED
Priority: P3 → P2
Target Milestone: --- → mozilla0.8
Assignee | ||
Comment 3•24 years ago
|
||
i have no idea why i said moz 0.8. i meant .9
Target Milestone: mozilla0.8 → mozilla0.9
Comment 4•24 years ago
|
||
correct term
Summary: Cursor comes back to previous line after selecting Paragraph Style → caret comes back to previous line after selecting Paragraph Style
Assignee | ||
Updated•23 years ago
|
Target Milestone: mozilla0.9.1 → mozilla0.9.2
Updated•23 years ago
|
Whiteboard: [QAHP] → [caret][QAHP]
Assignee | ||
Comment 6•23 years ago
|
||
Assignee | ||
Comment 7•23 years ago
|
||
Assignee | ||
Comment 8•23 years ago
|
||
attached patch fixes this problem. Now when we accumulate a candidate list of nodes to be made into a block, we don't insist the list be empty in order to make an empty block. Instead we check to see if there is any visible content beyond a single br. If there isn't we make empty block. The reason we have to detect the empty block case and handle it specially is that otherwise we will delete the empty block in postprocessing. If we know it's supposed to be empty we can set up the correct state to prevent that.
Whiteboard: [caret][QAHP] → [caret][QAHP] fix in hand
Comment 10•23 years ago
|
||
In: + while (isupports) + { + curNode = do_QueryInterface(isupports); + res = mHTMLEditor->DeleteNode(curNode); + if (NS_FAILED(res)) return res; + res = arrayOfNodes->RemoveElement(isupports); + if (NS_FAILED(res)) return res; + isupports = dont_AddRef(arrayOfNodes->ElementAt(0)); + } the call to + res = arrayOfNodes->RemoveElement(isupports); would be faster as + res = arrayOfNodes->RemoveElementAt(0); since it then does not attempt to search through the array for the item (how are you to know that it starts searching from the start?). + isupports = dont_AddRef(arrayOfNodes->ElementAt(0)); Does this return null if there are no more elements in the array? Perhaps your loop should be while (NS_SUCCEEDD(arrayOfNodes->Count(&nodeCount)) && nodeCount > 0) This loops appears twice in the patch. Can the code be factored?
Updated•23 years ago
|
Whiteboard: [caret][QAHP] fix in hand → [caret][QAHP] fix in hand need r=, sr=
Assignee | ||
Comment 11•23 years ago
|
||
will make changes based on reviews, need a=
Whiteboard: [caret][QAHP] fix in hand need r=, sr= → [caret][QAHP] fix in hand; need a=
Comment 12•23 years ago
|
||
a=blizzard on behalf of drivers for the trunk
Assignee | ||
Comment 13•23 years ago
|
||
fix checked in
Status: ASSIGNED → RESOLVED
Closed: 23 years ago
Resolution: --- → FIXED
Comment 14•23 years ago
|
||
verified that this now behaves exactly as on 4.x composer on all trunk builds 0620. u go joe!
Status: RESOLVED → VERIFIED
You need to log in
before you can comment on or make changes to this bug.
Description
•