Open Bug 98547 Opened 23 years ago Updated 2 years ago

sublists can get pulled up into parent list when changing list type

Categories

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

defect

Tracking

()

mozilla1.4beta

People

(Reporter: sujay, Unassigned)

References

(Blocks 1 open bug, )

Details

(Keywords: parity-chrome, Whiteboard: [list][QAHP-top] EDITORBASE-; 6 days[adt2])

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 beppe@netscape.com 2000-09-18 10:41 -------

setting to m19, p3



------- Additional Comments From beppe@netscape.com 2000-09-18 10:56 -------

usability issue, not functioning correctly



------- Additional Comments From jfrancis@netscape.com 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 beppe@netscape.com 2000-09-29 15:33 -------

Joe, please include the required information per the rtm checkin rules



------- Additional Comments From beppe@netscape.com 2000-10-09 10:51 -------

removing + per pdt sw rules



------- Additional Comments From jfrancis@netscape.com 2000-10-19 09:38 -------

this isn't rtm matierial.  moving to moz 0.9



------- Additional Comments From jfrancis@netscape.com 2001-01-15 22:36 -------

p2



------- Additional Comments From jfrancis@netscape.com 2001-02-02 14:36 -------

moving a bunch of 0.9 bugs to 0.9.1



------- Additional Comments From kin@netscape.com 2001-06-15 08:33 -------

Created an attachment (id=38607)
Test case mentioned in the bug.



------- Additional Comments From jfrancis@netscape.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
Whiteboard: [list][QAHP]
Target Milestone: --- → mozilla1.0
*** Bug 52675 has been marked as a duplicate of this bug. ***
Keywords: nsbeta1
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
Blocks: 104166
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
Blocks: 92278
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
Keywords: nsbeta1+
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.
Keywords: nsbeta1+nsbeta1
Whiteboard: [list][QAHP-top] EDITORBASE+; 6 days[adt2] → [list][QAHP-top] EDITORBASE; 6 days[adt2]
Target Milestone: mozilla1.0 → mozilla1.1alpha
Keywords: nsbeta1nsbeta1-
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.
Keywords: nsbeta1-nsbeta1
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
nsbeta1-. Joe is overloaded with higher priority EDITORBASE issues
Keywords: nsbeta1nsbeta1-
QA Contact: sujay → editor
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

Mass-removing myself from cc; search for 12b9dfe4-ece3-40dc-8d23-60e179f64ac1 or any reasonable part thereof, to mass-delete these notifications (and sorry!)

Hey Kathleen,
Can you reproduce this bug or should we close it?

Flags: needinfo?(brade)

I can reproduce the original report in Thunderbird HTML email compose window so I'm guessing that this is still a valid bug that can be reproduced in Firefox.

Flags: needinfo?(brade)

In the process of migrating remaining bugs to the new severity system, the severity for this bug cannot be automatically determined. Please retriage this bug using the new severity system.

Severity: major → --
You need to log in before you can comment on or make changes to this bug.