This only happens if part, not all, of the sublist is selected. To see this
problem, create an html document that looks like:
1. line 1
2. line 2
1. line 3
2. line 4
3. line 5
(using numbered lists and indention to create it).
Select from line 1 to line 4. Change to bulletted list (use the toolbar).
Now you will see:
* line 1
* line 2
* line 3
* line 4
1. line 5
when you should be seeing
* line 1
* line 2
* line 3
* line 4
1. line 5
This won't happen if the whole sublist is selected: ie from line 1 to line 5.
This bug started life as 51398, but I have broken it into two bugs because I
fixed part of the problem.
------- Additional Comments From firstname.lastname@example.org 2000-09-18 10:41 -------
setting to m19, p3
------- Additional Comments From email@example.com 2000-09-18 10:56 -------
usability issue, not functioning correctly
------- Additional Comments From firstname.lastname@example.org 2000-09-20 16:46 -------
changing to rtm per beppe.
------- Additional Comments From Phil Peterson 2000-09-20 17:56 -------
PDT agrees P1. Can't wait for this fix :-)
------- Additional Comments From email@example.com 2000-09-29 15:33 -------
Joe, please include the required information per the rtm checkin rules
------- Additional Comments From firstname.lastname@example.org 2000-10-09 10:51 -------
removing + per pdt sw rules
------- Additional Comments From email@example.com 2000-10-19 09:38 -------
this isn't rtm matierial. moving to moz 0.9
------- Additional Comments From firstname.lastname@example.org 2001-01-15 22:36 -------
------- Additional Comments From email@example.com 2001-02-02 14:36 -------
moving a bunch of 0.9 bugs to 0.9.1
------- Additional Comments From firstname.lastname@example.org 2001-06-15 08:33 -------
Created an attachment (id=38607)
Test case mentioned in the bug.
------- Additional Comments From email@example.com 2001-06-18 08:49 -------
pushing off. i know how to fix this one but it is a big change that shouldn't
be made this late in 092. Besides, there is an easy workaround.
*** Bug 52675 has been marked as a duplicate of this bug. ***
This bug has been around for over a year, and has QAHP on it. Is it reasonable
to expect it will get fixed?
This bug has an easy workaround, and is fairly hard to fix. That's why it gets
pushed off. I dont see this making 095 unless you want me to drop about 8 other
Bugs targeted at mozilla1.0 without the mozilla1.0 keyword moved to mozilla1.0.1
(you can query for this string to delete spam or retrieve the list of bugs I've
nominating this as QAHP-top (from discussion with Sujay)
plussing for the good of lists
Bulk moving all nsbeta1+ bugs which were targetted after Mozilla1.0 to Mozilla1.0
pri = 2 for original 1.0 EB+ bugs
*** Bug 98549 has been marked as a duplicate of this bug. ***
I think this only happens if the beginning and end of the
selection are at 2 different levels ... I remember fixing or a reviewing a fix
like this a while ago, but I think it was in the alignment or indenting code.
(sometime around the summer/joe's sabatical?)
Clearing EDITORBASE+ and nsbeta1 for re-consideration since the fix has been
determined to be both difficult and risky.
Joe, what is the risk, how long will this take to fix? This really looks like
the kind of thing we want for EDITORBASE.
nsHTMLEditRules::WillMakeList() is pretty complex. The approach it uses works
pretty well across a lot of different possible structures, but it doesn't track
relative nesting levels of nodes it is "listifying". Under many instances this
is not a problem. For example, if a list (or list item) which contains sublists
is acted on as a whole, the structre inside that will remain inside, and thus
still in the same place relative to it's parent. (Note in the original test case
how there is only a problem if *part* of a sublist is selected.)
I tried to find a simple way to change the basic algorithm here that would fix
this bug, and so far have not come up with one. Unless I do, the only other
approach is a wholesale rewrite of WillMakeList(). That is risky.
EDITORBASE-. Will revisit this later.
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.
Joe: Probably still to risky? Removing "-" for reconsideration for Buffy.
I don't know if I can get to this for Buffy or not. I'm concentrating on stuff
that is either higher profile or that doesn't have as simple a workaround.
[ushing these out as far as bugzilla will let me. I'll pull them back as I work
nsbeta1-. Joe is overloaded with higher priority EDITORBASE issues