Last Comment Bug 98547 - sublists can get pulled up into parent list when changing list type
: sublists can get pulled up into parent list when changing list type
Status: NEW
[list][QAHP-top] EDITORBASE-; 6 days[...
:
Product: Core
Classification: Components
Component: Editor (show other bugs)
: Trunk
: All All
: P2 major with 3 votes (vote)
: mozilla1.4beta
Assigned To: Nobody; OK to take it and work on it
:
Mentors:
: 52675 (view as bug list)
Depends on:
Blocks: 92278 104166
  Show dependency treegraph
 
Reported: 2001-09-06 10:32 PDT by sujay
Modified: 2007-04-05 04:10 PDT (History)
7 users (show)
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---


Attachments

Description sujay 2001-09-06 10:32:14 PDT
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.
Comment 1 sujay 2001-09-06 10:33:20 PDT
*** Bug 52675 has been marked as a duplicate of this bug. ***
Comment 2 Syd Logan 2001-09-11 13:47:02 PDT
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 Joe Francis 2001-09-12 01:23:47 PDT
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.
Comment 4 Asa Dotzler [:asa] 2001-12-03 11:15:22 PST
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)
Comment 5 Kathleen Brade 2002-01-11 11:58:10 PST
nominating this as QAHP-top (from discussion with Sujay)
Comment 6 Syd Logan 2002-01-22 17:33:01 PST
plussing for the good of lists
Comment 7 Kevin McCluskey (gone) 2002-02-19 18:13:54 PST
Bulk moving all nsbeta1+ bugs which were targetted after Mozilla1.0 to Mozilla1.0
Comment 8 Joe Francis 2002-02-28 17:19:56 PST
pri = 2 for original 1.0 EB+ bugs
Comment 9 kinmoz 2002-03-06 10:35:22 PST
*** Bug 98549 has been marked as a duplicate of this bug. ***
Comment 10 kinmoz 2002-03-06 10:36:56 PST
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?)
Comment 11 Kevin McCluskey (gone) 2002-04-01 11:14:23 PST
Clearing EDITORBASE+ and nsbeta1 for re-consideration since the fix has been
determined to be both difficult and risky.
Comment 12 Syd Logan 2002-04-04 18:23:03 PST
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 Joe Francis 2002-04-09 18:13:30 PDT
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.
Comment 14 Kevin McCluskey (gone) 2002-04-18 14:25:03 PDT
EDITORBASE-. Will revisit this later.
Comment 15 Joe Francis 2002-07-23 16:00:41 PDT
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.
Comment 16 Charles Manske 2002-08-12 14:41:35 PDT
Joe: Probably still to risky? Removing "-" for reconsideration for Buffy.
Comment 17 Joe Francis 2002-09-01 16:00:58 PDT
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 Joe Francis 2002-09-07 19:25:27 PDT
[ushing these out as far as bugzilla will let me.  I'll pull them back as I work
on them.
Comment 19 Kevin McCluskey (gone) 2002-11-11 12:10:20 PST
nsbeta1-. Joe is overloaded with higher priority EDITORBASE issues

Note You need to log in before you can comment on or make changes to this bug.