caret comes back to previous line after selecting Paragraph Style

VERIFIED FIXED in mozilla0.9.2

Status

()

Core
Editor
P2
normal
VERIFIED FIXED
18 years ago
17 years ago

People

(Reporter: Srinivasa Rao Borusu, Assigned: Joe Francis)

Tracking

Trunk
mozilla0.9.2
x86
Windows NT
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [caret][QAHP] fix in hand; need a=)

Attachments

(2 attachments)

(Reporter)

Description

18 years ago
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

18 years ago
assigning to jfrancis
Assignee: beppe → jfrancis
Status: UNCONFIRMED → NEW
Ever confirmed: true
(Assignee)

Comment 2

18 years ago
accepting bug; moz0.8
Status: NEW → ASSIGNED
Priority: P3 → P2
Target Milestone: --- → mozilla0.8
(Assignee)

Comment 3

18 years ago
i have no idea why i said moz 0.8.  i meant .9
Target Milestone: mozilla0.8 → mozilla0.9

Comment 4

18 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)

Comment 5

18 years ago
appeasing bug gods
Target Milestone: mozilla0.9 → mozilla0.9.1

Updated

18 years ago
Whiteboard: [QAHP]
(Assignee)

Updated

18 years ago
Target Milestone: mozilla0.9.1 → mozilla0.9.2

Updated

17 years ago
Whiteboard: [QAHP] → [caret][QAHP]
(Assignee)

Comment 6

17 years ago
Created attachment 35709 [details] [diff] [review]
diffs for editor/base/nsHTMLEditRules.h
(Assignee)

Comment 7

17 years ago
Created attachment 35710 [details] [diff] [review]
diffs of editor/base/nsHTMLEditRules.cpp
(Assignee)

Comment 8

17 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
(Assignee)

Comment 9

17 years ago
*** Bug 72886 has been marked as a duplicate of this bug. ***

Comment 10

17 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

17 years ago
Whiteboard: [caret][QAHP] fix in hand → [caret][QAHP] fix in hand need r=, sr=
(Assignee)

Comment 11

17 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=
a=blizzard on behalf of drivers for the trunk
(Assignee)

Comment 13

17 years ago
fix checked in
Status: ASSIGNED → RESOLVED
Last Resolved: 17 years ago
Resolution: --- → FIXED

Comment 14

17 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.