Open
Bug 552782
Opened 14 years ago
Updated 3 years ago
Outlines: Numbering is wrong
Categories
(Core :: DOM: Editor, defect, P5)
Core
DOM: Editor
Tracking
()
NEW
People
(Reporter: ned.phipps, Unassigned)
Details
(Whiteboard: [only test landed, don't close on inbound merge])
Attachments
(1 file)
2.37 KB,
patch
|
ehsan.akhgari
:
review+
|
Details | Diff | Splinter Review |
User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.1; GTB6.4; .NET CLR 1.1.4322; .NET CLR 2.0.50727; .NET CLR 3.0.04506.30; .NET CLR 3.0.4506.2152; .NET CLR 3.5.30729) Build Identifier: Outline numbers are wrong if outdent then indent. Reproducible: Always Steps to Reproduce: 1.Start an outline 2.Make three sub-items in a set 3.Outdent item 2 so its at the main level 4.Indent item 2 so its back where it was Actual Results: ***Item 2 has the number 1 instead of 2 Expected Results: The numbers should be the same as before step 3 The software leaves this above the item 2 in the file: </ol> <ol>
Reporter | ||
Updated•14 years ago
|
Component: General → Composer
Version: unspecified → SeaMonkey 2.0 Branch
This is probably an issue with core than with SM composer
Status: UNCONFIRMED → NEW
Component: Composer → Editor
Ever confirmed: true
OS: Windows XP → All
Product: SeaMonkey → Core
QA Contact: general → editor
Hardware: x86 → All
Version: SeaMonkey 2.0 Branch → Trunk
Actually what I see on current trunk, after outdenting and then indenting "Item 2" is: 1. Item 1 Item 2 1. Item 3 Would we expect it to be: 1. Item 1 2. Item 2 3. Item 3 ? If starting with something indented more and then outdenting item 2 once, would we expect it to be: 1. Item 1 1. Item 2 1. Item 3 but it is: 1. Item 1 Item 2 1. Item 3 Then reindenting after, gives: 1. Item 1 Item 2 1. Item 3 But would expect: 1. Item 1 2. Item 2 3. Item 3 Reindenting "Item 2" from: 1. Item 1 1. Item 2 1. Item 3 Gives: 1. Item 1 1. Item 2 2. Item 3 But would expect: 1. Item 1 2. Item 2 3. Item 3
Comment 3•13 years ago
|
||
Hmm, this is interesting... I understand the desired opposite behavior of indent and outdent, but I'm not sure if it makes sense to put item 2 back in the list or not...
I would say that is wrong behaviour for a single outdent of one item in a twice indented list to remove all indents for that item though. The question is, should it be: 1. Item 1 1. Item 2 1. Item 3 or: 1. Item 1 Item 2 1. Item 3 or something else?
Comment 5•13 years ago
|
||
This is all a huge, huge complicated mess. (Moreso than most of editing.) I spent a long time researching what various UAs do and thinking about it, and the results are summarized in the giant comment here: http://aryeh.name/spec/editing/editing.html#toggling-lists My conclusion was that the list marker should always be one plus the list marker of the previous item of the same indentation level, assuming nothing of lower indentation level intervenes. The upshot of that is we should never produce </ol><ol>. The lists should always be merged in that case. Thus if you have <ol> <li>foo</li> <ol> <li>bar</li> <li>baz</li> <li>quz</li> </ol> </ol> and you outdent "baz", it should become <ol> <li>foo</li> <ol><li>bar</li></ol> <li>baz</li> <ol><li>quz</li></ol> </ol> </ol> Then if you indent "baz", it should join with the existing two lists and (in this case) you should get the original markup back. Having two lists that are adjacent but have different numbering doesn't make sense for WYSIWYG, IMO, unless the user manually sets the numbers somehow (<li value>). The exact details of toggling lists are one of the most complicated parts of the spec, though.
Comment 6•13 years ago
|
||
The steps should never generate two lists. Step 1 -- create: 1. A 1. B1 2. B2 3. B3 Step 2 -- outdent 1. A 1. B1 2. B2 1. B3 Step 3 -- re-indent should give 1. A 1. B1 2. B2 3. B3 Instead it gives: 1. A 1. B1 1. B2 2. B3
Comment on attachment 561020 [details] [diff] [review] Test Test for outdenting/indenting issue described in comment 6
Attachment #561020 -
Flags: review?(ehsan)
Comment 9•13 years ago
|
||
Comment on attachment 561020 [details] [diff] [review] Test Ian, if you have run this through the try server, we can land it.
Attachment #561020 -
Flags: review?(ehsan) → review+
Comment 10•13 years ago
|
||
Try run for 6886b03f63e8 is complete. Detailed breakdown of the results available here: https://tbpl.mozilla.org/?tree=Try&rev=6886b03f63e8 Results (out of 31 total builds): success: 30 warnings: 1 Builds available at http://ftp.mozilla.org/pub/mozilla.org/firefox/try-builds/iann_cvs@blueyonder.co.uk-6886b03f63e8
Keywords: checkin-needed
Updated•13 years ago
|
Assignee: nobody → iann_bugzilla
Updated•13 years ago
|
Assignee: nobody → iann_bugzilla
Status: NEW → ASSIGNED
Target Milestone: --- → mozilla9
Comment 12•13 years ago
|
||
This bug is not fixed by Ian's patch, and I don't know if he's volunteered to write the fix in addition to writing the test, so let's not assign it to him or set the target milestone, etc. in-testsuite+ is the only thing this check-in needs.
Assignee: iann_bugzilla → nobody
Target Milestone: mozilla9 → ---
Comment 13•13 years ago
|
||
Oh |todo_is|. My skim read whilst preparing this for checkin-needed (before you beat me to it hehe) thought this was a WFM since originally reported, but a test added to make sure it didn't regress.
Updated•13 years ago
|
Whiteboard: [only test landed, don't close on inbound merge]
Updated•13 years ago
|
Status: ASSIGNED → NEW
Comment 14•13 years ago
|
||
test merge https://hg.mozilla.org/mozilla-central/rev/1384ec5bb542
Comment 15•3 years ago
|
||
Bulk-downgrade of unassigned, >=5 years untouched DOM/Storage bugs' priority.
If you have reason to believe this is wrong (especially for the severity), please write a comment and ni :jstutte.
Severity: normal → S4
Priority: -- → P5
You need to log in
before you can comment on or make changes to this bug.
Description
•