Improper list properties when text has been formatted

NEW
Unassigned

Status

()

defect
18 years ago
12 years ago

People

(Reporter: TucsonTester1, Unassigned)

Tracking

Trunk
mozilla1.4beta
x86
Windows 2000
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

Reporter

Description

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

Comment 1

18 years ago
Update: the <HR> is not necessary.  Only the bold is required.
Summary: Improper list properties when text has been formatted and <HR> present → Improper list properties when text has been formatted

Comment 2

18 years ago
Confirmed with 2001-12-10-03 under W2K
Status: UNCONFIRMED → NEW
Ever confirmed: true

Comment 3

18 years ago
-->core (jfrancis)
Assignee: syd → jfrancis
Component: Editor: Composer → Editor: Core

Comment 4

18 years ago
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
Status: NEW → ASSIGNED
Target Milestone: --- → mozilla0.9.9

Comment 5

18 years ago
the swami says: things that will not land in 099!
Target Milestone: mozilla0.9.9 → mozilla1.0
Moving bugs to Mozilla1.1 that are not EDITORBASE+.
Target Milestone: mozilla1.0 → mozilla1.1
Moving bugs to Mozilla1.1 that are not EDITORBASE+.

Comment 8

17 years ago
The trunk is the wave of the future!
Target Milestone: mozilla1.1alpha → mozilla1.1beta

Comment 9

17 years ago
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.
Target Milestone: mozilla1.1beta → mozilla1.2beta

Comment 10

17 years ago
migrating milestones now that there are more available.  i'll pull these back as
I work on them
Target Milestone: mozilla1.2beta → mozilla1.4beta
QA Contact: sujay → editor
Assignee: mozeditor → nobody
Status: ASSIGNED → NEW
You need to log in before you can comment on or make changes to this bug.