99517 - Text migrates past H. Line, loses formatting when converted to list

Status: VERIFIED FIXED

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

Description

[TucsonTester1]

Description:

In Composer, lines or paragraphs of text--if are separated by breaks (or
carriage returns) and Horizontal Lines--will migrate and become joined together
at the top of a document when entire document is highlighted and toggled as a
list.  H. Lines, likewise, become grouped at the bottom of the document.


Reproducibility: Always


Steps to recreate:

        (1) Open a new, blank Composer window
        (2) As if is was a word, type the characters
                ``12345'' (without the quotes) on 
                the first line
        (3) Press <Enter> once
        (4) Insert a Horizontal Line using default
                values
        (5) Press <Enter> once more
        (6) As if is was a word, type the characters
                ``ABCDE'' (without the quotes) on 
                this line where the cursor now 
                rests
        (7) Select all
        (8) Click either List button on the Toolbar
                (I choose the Numbered List button)



Actual results:

Observe that on the first click of the List button the three items highlighted,
including the H. Line itself, become list items. The Horiz. Line is missing a
leading number or dot, however.  In the case of a Numbered List, notice the
sequence.  Now, clicking the same List button a second time changes the items
from list items *and* floats the bottom text string to directly underneath the
first one.  The Horizontal line is now on the bottom.  Clicking a list button a
third time appends the second string of information to end of the first,
creating one long word of the two.  This can be verified in the <HTML> Source
tab.  Also what appears is an apparent second line, as in Bug 96455.

On the next click of the button there are now only two list items, the Line has
become the second, and again lacks a leading number or dot.  Subsequent clicks
of the same Toobar button do not affect the text further, other than to it
toggle its state as a list item.  As for the H. Line, however, more apparent
lines are generated, per Bug 96455.


Expected results:

Toggling-off a highlighted list should undo changes, returning information to
its previous state.  For the text involved, the second string of text should not
migrate, much less, become appended to the the first string.

The Line should not appear replicated.  Additionally, an H.L. may be used as a
separator within a list if desired, however it should not itself become a
numbered list item.  See Bug 96455.



Additional Information: 

The text behaviour appears to be dependant on Bug 96455.

Comment 1

[Kathleen :Brade]

-->kin

Comment 2

[michael wendell]

Confirmed on build 2001091303

Comment 3

[kinmoz]

The wierdness with the HR has to do with the fact that layout is creating an
extra HR frame whenever an HR is added to the content tree. (Bug 96455)

Comment 4

[kinmoz]

Attachment: Patch Rev 1 (Make sure we reset prevListItem, after a block)

Comment 5

[kinmoz]

There are actually 3 bugs pointed out here in this bug:

1. HR line gets duplicated. (Bug 96455)
2. Bullet missing or number drawing on top of list item containing HR.
3. Content out of order during make list.

I just posted a patch for 96455. I'll have to look into #2 and I just attatched 
Patch Rev 1 which fixes #3 by handling most block cases which don't involve divs 
and table elements.

Comment 6

[Joe Francis]

Comment on attachment 56106 [details] [diff] [review]
Patch Rev 1 (Make sure we reset prevListItem, after a block)

r=jfrancis

Comment 7

[kinmoz]

Just an FYI, divs and table elements (td, tr, etc) are not covered but Patch Rev 
1 ... they can still be out of order after making them into a list. That is 
covered by bug 108035.

Comment 8

[kinmoz]

I just filed bug 108053 to cover the bullet/number of the list item 
missing or overlapping the HR.

So this bug now only covers #3 in my list above ... the fact that the content 
is put in the list out of order.

Comment 9

[Simon Fraser [no longer active]]

Comment on attachment 56106 [details] [diff] [review]
Patch Rev 1 (Make sure we reset prevListItem, after a block)

sr=sfraser

Comment 10

[kinmoz]

Fix checked into trunk:

    mozilla/editor/libeditor/html/nsHTMLEditRules.cpp  revision 1.205

Comment 11

[michael wendell]

Verified.