98286 - Changing from body text to paragraph causes the caret to get stuck

Status: VERIFIED FIXED

(Core :: DOM: Editor, defect)

Description

[TucsonTester2]

From Bugzilla Helper:
User-Agent: Mozilla/4.0 (compatible; MSIE 5.5; Windows 95)
BuildID:    2001083003

After changing from body text selection to paragraph text the cursor gets stuck 
and you are not able to tap the enter key and have the cursor move further down 
the page. 

Reproducible: Always
Steps to Reproduce:
1.Open blank a composer page and change from body text to paragraph.Type a few 
lines of text tap enter 2 or 3 times
2.Change back to body text and type a few more lines of text tap enter 2 or 3 
times
3.Change back to paragraph text and type a few more lines of text then try to 
tap enter multiple times.

Actual Results:  When you tap the enter key the cursor will not continue to go 
down the page it will only jump up and down. 

Expected Results:  Expected to see the cursor move as far down the page as it 
could.

If you go back to body text the cursor acts normally but going back to 
paragraph text you get the same reults. Using the arrow key doesn't move the 
cursor down either when you are on paragraph text but it will move it up.

Comment 1

[Kathleen :Brade]

-->jfrancis

Joe--is this a bug for you or is it a selection bug?

Comment 2

[michael wendell]

Confirmed on Win2k using build 2001092405.

Comment 3

[Joe Francis]

probably me.  097

Comment 4

[Syd Logan]

This worksforme

Comment 5

[michael wendell]

I am still seeing this problem on Win 2k using build 2001121703.

I am reopening this bug. 

I have some easier steps to reproduce:
1. Open Composer
2. Choose "Paragraph" from the text style drop down
3. Type one line of text, and hit enter 3 times
4. Choose "Body Text" from the text style drop down
5. Type one line of text, and hit enter 3 times
6. Choose "Paragraph" from the text style drop down
7. Type one line of text, and hit enter 4 times

Notice that the 4th time you hit enter, the caret jumps up.  

Comment 6

[TucsonTester1]

This issue is also occuring on Mac OS X Build 2001121405. 

Comment 7

[michael wendell]

Switching Platform and OS to all / all per above comments.

Comment 8

[Syd Logan]

plussing

Comment 9

[Joe Francis]

Attachment: diffs for nsHTMLEditRules.h

Comment 10

[Joe Francis]

Attachment: diffs for nsHTMLEditRules.cpp

I took this opportunity to refactor ReturnInParagraph().  Kin and Daniel will
have much easier lives now if they need to work with it!  Common code for
splitting the paragraph was factored out into a seperate routine.  I discovered
we were not always checking for empty paragraphs created by the split, so that
is now fixed since the code is in one place instead of three.  The only change
that specifically applies to fixing this bug is in the new routine
SplitParagraph(), and is the where we delete the break *if* it is visible.  The
bug was we were always deleting it before, which could lead to an empty
paragraph, and since we weren't consistently repopulating empty paragraphs with
br's, it would get deleted.

also note that I have incorporated Daniel's work from bug 46474 here, albeit in
a much simpler form.  That is what the GetLeftmostChild() call is doing for us
near the end of the patch: finding where we want to put selection.

Comment 11

[Daniel Glazman (:glazou) (not active in Mozilla any more)]

Comment on attachment 68828 [details] [diff] [review]
diffs for nsHTMLEditRules.cpp

>+		    *aHandled = PR_TRUE;
>+		    res = SplitParagraph(aPara, sibling, aSelection, address_of(selNode), &aOffset);

...

>+		    *aHandled = PR_TRUE;
>+		    res = SplitParagraph(aPara, sibling, aSelection, address_of(selNode), &aOffset);

Alignment uses tabs instead of whitespaces.

r=glazman

Comment 12

[kinmoz]

Comment on attachment 68828 [details] [diff] [review]
diffs for nsHTMLEditRules.cpp

sr=[e-mail]

With indentation fix mentioned by glazman.

Comment 13

[Joe Francis]

fixed on tip

Comment 14

[michael wendell]

Verified on Win XP using trunk build 02-20.