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 have 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 ------- p2 ------- 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.
Severity: normal → major
Target Milestone: --- → mozilla1.0
*** 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 095 bugs.
Status: NEW → ASSIGNED
Whiteboard: [list][QAHP] → [list][QAHP] EDITORBASE; 6 days
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 moved)
Target Milestone: mozilla1.0 → mozilla1.0.1
nominating this as QAHP-top (from discussion with Sujay)
Whiteboard: [list][QAHP] EDITORBASE; 6 days → [list][QAHP-top] EDITORBASE; 6 days
plussing for the good of lists
Whiteboard: [list][QAHP-top] EDITORBASE; 6 days → [list][QAHP-top] EDITORBASE+; 6 days
Bulk moving all nsbeta1+ bugs which were targetted after Mozilla1.0 to Mozilla1.0
Target Milestone: mozilla1.0.1 → mozilla1.0
pri = 2 for original 1.0 EB+ bugs
Priority: -- → P2
*** 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?)
Whiteboard: [list][QAHP-top] EDITORBASE+; 6 days → [list][QAHP-top] EDITORBASE+; 6 days[adt2]
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.
Whiteboard: [list][QAHP-top] EDITORBASE; 6 days[adt2] → [list][QAHP-top] EDITORBASE-; 6 days[adt2]
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.1alpha → mozilla1.2beta
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 on them.
Target Milestone: mozilla1.2beta → mozilla1.4beta
Assignee: mozeditor → nobody
Status: ASSIGNED → NEW
Moving to p3 because no activity for at least 1 year(s). See https://github.com/mozilla/bug-handling/blob/master/policy/triage-bugzilla.md#how-do-you-triage for more information
Priority: P2 → P3
You need to log in before you can comment on or make changes to this bug.