187662 - unable to insert <br> in an empty document at the first time

Status: VERIFIED FIXED

(Core :: DOM: Editor, defect)

Description

[Kyle Yuan]

Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3b) Gecko/20030103

steps:
1. open composer;
2. press <Enter>.

result:
nothing happen. press <Enter> again will insert <br> correctly.

Comment 1

[Kyle Yuan]

brade, kin, any idea?

Comment 2

[kinmoz]

I think the changes for bug 174017 may have caused this regression.

When I hit return, the bogus br node is removed, so we have a selection that is
inside an empty body. The changes made for 174017 in
|nsHTMLEditRules::StandardBreakImpl()| then cause  both |bAfterBlock| and
|bBeforeBlock| to be set to  true so we never add the needed 2nd br.

jfrancis, for both ws calls the node passed in is the body, and the returned
visNode is also the body. Perhaps we need to special case for that situation?

Comment 3

[Joe Francis]

Attachment: patch to nsHTMLEditRules.cpp

when inserting a break, check for an empty block after doing any deletion and
bogus node removal.  If block is empty populate it with a br before continueing
on with break insertion code.

Comment 4

[Kathleen :Brade]

Comment on attachment 110976 [details] [diff] [review]
patch to nsHTMLEditRules.cpp

in this block in nsHTMLEditRules.cpp (around line 1515):
+  if (isEmpty)
+  {
+    nsCOMPtr<nsIDOMNode> brNode;
+    PRUint32 blockLen;
+    res = mHTMLEditor->GetLengthOfDOMNode(blockParent, blockLen);

move the nsCOMPtr declaration down until after you call GetLengthOfDOMNode

r=brade with that

Comment 5

[kinmoz]

Comment on attachment 110976 [details] [diff] [review]
patch to nsHTMLEditRules.cpp

sr=[e-mail]

Comment 6

[Kevin McCluskey (gone)]

EDITORBASE+, nsbeta1+

Comment 7

[Samir Gehani]

Composer triage team: nominating for topembed (nsbeta1 is used for composer
application defects).

Comment 8

[Joe Francis]

This was checked in on tip a week ago.

Comment 9

[sairuh (rarely reading bugmail)]

vrfy'd fixed on all platforms with recent trunk bits.