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

NEW
Unassigned

Status

()

Core
Editor
P2
major
16 years ago
10 years ago

People

(Reporter: sujay, Unassigned)

Tracking

Trunk
mozilla1.4beta
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [list][QAHP-top] EDITORBASE-; 6 days[adt2])

(Reporter)

Description

16 years ago
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.
(Reporter)

Updated

16 years ago
Severity: normal → major
Whiteboard: [list][QAHP]
Target Milestone: --- → mozilla1.0
(Reporter)

Comment 1

16 years ago
*** Bug 52675 has been marked as a duplicate of this bug. ***
(Reporter)

Updated

16 years ago
Keywords: nsbeta1

Comment 2

16 years ago
This bug has been around for over a year, and has QAHP on it. Is it reasonable
to expect it will get fixed?

Comment 3

16 years ago
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.

Updated

16 years ago
Status: NEW → ASSIGNED
Whiteboard: [list][QAHP] → [list][QAHP] EDITORBASE; 6 days

Updated

16 years ago
Blocks: 104166

Comment 4

16 years ago
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

Updated

16 years ago
Blocks: 92278

Comment 5

16 years ago
nominating this as QAHP-top (from discussion with Sujay)
Whiteboard: [list][QAHP] EDITORBASE; 6 days → [list][QAHP-top] EDITORBASE; 6 days

Comment 6

16 years ago
plussing for the good of lists
Whiteboard: [list][QAHP-top] EDITORBASE; 6 days → [list][QAHP-top] EDITORBASE+; 6 days

Updated

16 years ago
Keywords: nsbeta1+
Bulk moving all nsbeta1+ bugs which were targetted after Mozilla1.0 to Mozilla1.0
Target Milestone: mozilla1.0.1 → mozilla1.0

Comment 8

15 years ago
pri = 2 for original 1.0 EB+ bugs
Priority: -- → P2

Comment 9

15 years ago
*** Bug 98549 has been marked as a duplicate of this bug. ***

Comment 10

15 years ago
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?)

Updated

15 years ago
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]

Updated

15 years ago
Target Milestone: mozilla1.0 → mozilla1.1alpha

Updated

15 years ago
Keywords: nsbeta1 → nsbeta1-

Comment 12

15 years ago
Joe, what is the risk, how long will this take to fix? This really looks like 
the kind of thing we want for EDITORBASE.

Comment 13

15 years ago
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]

Comment 15

15 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.1alpha → mozilla1.2beta

Comment 16

15 years ago
Joe: Probably still to risky? Removing "-" for reconsideration for Buffy.
Keywords: nsbeta1- → nsbeta1

Comment 17

15 years ago
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.

Comment 18

15 years ago
[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: nsbeta1 → nsbeta1-
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.