114509 - Improper list properties when text has been formatted

Status: NEW

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

Description

[TucsonTester1]

From Bugzilla Helper:
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.6+)
Gecko/20011210 Netscape6/6.2.1+
BuildID:    2001121003

When creating a list, then formatting the text, if you place an <HR>, the list
does not function as normal.

Reproducible: Always
Steps to Reproduce:
1. Launch composer.
2. Click on the numbered list icon in the toolbar.
3. Create 3 list items (type text, press enter, text, enter, text, enter).
4. Click on Edit, then Select All, then click on the 'Bold' icon in the toolbar
(or italic or underline)
5. Unselect the highlighted text, then insert a horizontal line.
6. Press enter repeatedly.

Actual Results:  Each time enter is pressed, a new line in the list is created.

Expected Results:  Normally, after the second time enter is pressed, the list is
discontinued, and the caret is placed at the beginning of a brand new line. 
This normal behavior does happen, if the bold is not present.

I have also noticed that, when you are far down on the list, after pressing
enter a number of times (say on the 8th line), if you press backspace once, the
caret moves to the seventh line.  Then, after pressing the backspace key again,
the 8th line disappears, and the caret jumps to the 3rd line.

I hope i have conveyed this correctly, this has seemed to be difficult to describe.

Comment 1

[TucsonTester1]

Update: the <HR> is not necessary.  Only the bold is required.

Comment 2

[eberry]

Confirmed with 2001-12-10-03 under W2K

Comment 3

[Kathleen :Brade]

-->core (jfrancis)

Comment 4

[Joe Francis]

note to self: the cause here is that the test for emptiness of a list item is
not  being agressive enough.  the li in question contains <b><br><b/>, which
should count as empty.  Once I fix that, I should then modify the splitting code
to not generate the "bold break" to start with, and instead split the br outside
of the b.  

099

Comment 5

[Joe Francis]

the swami says: things that will not land in 099!

Comment 6

[Kevin McCluskey (gone)]

Moving bugs to Mozilla1.1 that are not EDITORBASE+.

Comment 7

[Kevin McCluskey (gone)]

Moving bugs to Mozilla1.1 that are not EDITORBASE+.

Comment 8

[Joe Francis]

The trunk is the wave of the future!

Comment 9

[Joe Francis]

The days of having a half dozen milestones out in front of us to divide bugs 
between seem to be gone, though I dont know why.  Lumping everything together as 
far out as I can.  I'll pull back things that I am working on as I go.

Comment 10

[Joe Francis]

migrating milestones now that there are more available.  i'll pull these back as
I work on them

Comment 11

[Jens Stutte [:jstutte]]

Bulk-downgrade of unassigned, >=5 years untouched DOM/Storage bugs' priority.

If you have reason to believe this is wrong (especially for the severity), please write a comment and ni :jstutte.