Fix nested lists interrupted by paragraphs losing structure and consecutive numbering.

[mmotyczynska]

🚀 Summary

When pasting content from Word that contains a numbered or bulleted list item followed by a nested list interrupted by plain paragraphs, the paragraphs were placed in the wrong position — after all nested list items instead of between them.

Source (Word):

Result before fix:

1. Item 1
   • Item 2
   • Item 3
   • Item 4
   • Item 5
   Paragraph 1
   Paragraph 2
   Paragraph 3
   Paragraph 4

Result after fix:

1. Item 1
   
   • Item 2
   Paragraph 1
   • Item 3
   Paragraph 2
   • Item 4
   Paragraph 3
   • Item 5
   Paragraph 4

Root cause

Word HTML represents list items as flat <p> elements with mso-list styles rather than semantic <ul>/<ol>/<li>. The paste-from-office normalizer reconstructs list structure using a stack and margin-left matching. Nested list items sometimes have no explicit margin-left style on their <p> element, so they never match the stack-based lookup — only the ancestor <li> matches. As a result, continuation paragraphs were correctly placed inside the ancestor list item, but the internal stack was not trimmed afterwards. This caused the next nested list item to be appended to the pre-existing nested <ol>/<ul> — the one appearing before the paragraph in the DOM — instead of creating a new list after it.

Fix

After appending a continuation paragraph to the matched ancestor <li>, the stack is now trimmed to that ancestor's level. This forces subsequent nested list items to create a new <ol>/<ul> positioned after the paragraph.

Consecutive numbering for interrupted ordered lists

The fix inherently splits a nested ordered list into multiple separate <ol> elements (one per segment between paragraphs). To preserve correct numbering, the existing start attribute mechanism — which already handled interrupted top-level ordered lists — has been extended to all nesting levels. Each resumed <ol> now receives a start attribute reflecting the count of items already rendered in previous segments:

<ol>
  <li>
    Item 1
    <ol><li>Item 2</li></ol>
    Paragraph 1
    <ol start="2"><li>Item 3</li></ol>
    Paragraph 2
    <ol start="3"><li>Item 4</li></ol>
  </li>
</ol>

Note: this is a static start attribute set at paste time, not dynamic renumbering — if the user edits the list after pasting, the editor's normal list handling takes over.

---

📌 Related issues

• Closes Pasting interrupted lists from Word breaks list structure #19127

---

💡 Additional information

The ticket described the problem as paragraphs appearing in the wrong order. The interpretation taken here is that paragraphs should be interleaved between nested list items at the same visual indentation level — matching what the user sees in Word. This interpretation is what makes the consecutive numbering fix a natural and necessary part of the solution: once the structure is split into separate <ol> segments, numbering continuity cannot be maintained without start.

---

🧾 Checklists

Use the following checklists to ensure important areas were not overlooked.
This does not apply to feature-branch merges.
If an item is not relevant to this type of change, simply leave it unchecked.

Author checklist

• Is the changelog entry intentionally omitted?
• Is the change backward-compatible?
• Have you considered the impact on different editor setups and core interactions? (e.g., classic/inline/multi-root/many editors, typing, selection, paste, tables, lists, images, collaboration, pagination)
• Has the change been manually verified in the relevant setups?
• Does this change affect any of the above?
• Is performance impacted?
• Is accessibility affected?
• Have tests been added that fail without this change (against regression)?
• Have the API documentation, guides, feature digest, and related feature sections been updated where needed?
• Have metadata files (ckeditor5-metadata.json) been updated if needed?
• Are there any changes the team should be informed about (e.g. architectural, difficult to revert in future versions or having impact on other features)?
• Were these changes documented (in Logbook)?

Reviewer checklist

• PR description explains the changes and the chosen approach (especially when performance, API, or UX is affected).
• The changelog entry is clear, user‑ or integrator-facing, and it describes any breaking changes.
• All new external dependencies have been approved and mentioned in LICENSE.md (if any).
• All human-readable, translateable strings in this PR been introduced using t() (if any).
• I manually verified the change (e.g., in manual tests or documentation).
• The target branch is correct.