fix(ExportHtml): preserve nested ol start across sibling ul

[JohnMcLear]

Summary

Round-tripping <ul>...<ul>...</ul></ul><ol><li>x<ol><li>y</li></ol></li></ol> through setHTML → getHTML was emitting the inner <ol> as <ol class=\"number\"> instead of the expected <ol start=\"2\" class=\"number\">.

Root cause: the depth-decrease loop in getHTMLFromAtext resets olItemCounts[level] = 0 to signal "this ol level was explicitly closed, don't fall back to line.start next time it reopens" (#7470). The gate only checked depth, not list type, so closing a bullet <ul> at depth 2 was also writing olItemCounts[2] = 0. When a later, unrelated <ol> opened at depth 2, the ol-opening logic took the "counter exists but is 0" branch and dropped line.start.

Fix: only run the counter reset when the line being closed is itself a number list. UL closures no longer touch ol bookkeeping.

Trade-off

The 0-sentinel design from #7470 still applies for genuine ol-close cases — if you close an ol and reopen one later at the same depth, line.start is still ignored (per that PR's intent). This change narrows the gate; it doesn't reverse the prior decision.

Test plan

Backend sweep on a fresh develop clone (Node 24.14.0):

• Before: 6 failing — appendTextAuthor x1, importexportGetPost x2, pad.ts x3 ("Get Authors of the Pad", "Pad with complex nested lists of different types", "copyPadWithoutHistory > creates a new pad with the same content as the source pad").
• After: 4 failing — the two pad.ts nested-list cases now pass. The other 4 failures are unrelated (Failing backend test: listAuthorsOfPad returns 1 author after setHTML when 0 expected #7785, Failing backend test: non-numeric :rev export returns 500 without 'rev is not a number' body #7788, Failing backend test: appendText without authorId still attributes one author #7790) and tracked separately.
• 1438 passing, 21 pending. No regressions in tests/backend/specs/api/ or tests/backend/specs/admin/.

Note: these failures are currently invisible in CI because of the broken backend test glob — see #7789, which has to land for CI to actually run these tests.

Fixes #7786
Fixes #7787

🤖 Generated with Claude Code

[qodo-code-review]

Qodo reviews are paused for this user.

Troubleshooting steps vary by plan Learn more →

On a Teams plan?
Reviews resume once this user has a paid seat and their Git account is linked in Qodo.
Link Git account →

Using GitHub Enterprise Server, GitLab Self-Managed, or Bitbucket Data Center?
These require an Enterprise plan - Contact us
Contact us →

[qodo-free-for-open-source-projects]

Review Summary by Qodo

Prevent ul closure from poisoning ol counter at same depth

🐞 Bug fix

Walkthroughs

Description

• Fix nested ordered list start attribute loss when sibling unordered list closes
• Gate ordered-list counter reset on list type to prevent unordered list closures from poisoning ol
  bookkeeping
• Preserve line.start for unrelated ordered lists at same depth after unordered list closure

Diagram

flowchart LR
  A["Closing UL at depth N"] --> B["Check list type"]
  B --> C["Type is 'number'?"]
  C -->|Yes| D["Reset olItemCounts[N]"]
  C -->|No| E["Skip reset"]
  D --> F["Later OL at depth N uses line.start"]
  E --> F

Loading

File Changes

1. src/node/utils/ExportHtml.ts 🐞 Bug fix +4/-1

Gate ol counter reset on list type check

• Added type check line.listTypeName === 'number' to gate the olItemCounts reset logic
• Only reset ordered-list counter when closing an actual ordered list, not unordered lists
• Updated comment to clarify that unordered list closures must not affect ol bookkeeping
• Prevents unrelated ordered lists at same depth from losing their start attribute

src/node/utils/ExportHtml.ts

---

[qodo-free-for-open-source-projects]

Code Review by Qodo

🐞 Bugs (0) 📘 Rule violations (0) 📎 Requirement gaps (0)

Great, no issues found!

Qodo reviewed your code and found no material issues that require review