Re-mark up the page after an Undo or Redo (BL-16558)

[JohnThomson]

Follow-up to #8123: the reader and Talking Book highlights were not being adjusted after an Undo or Redo changed the text.

Since BL-16558 the tools paint their highlights as ::highlight() pseudo-elements over live Range objects rather than by wrapping text in spans. An undo does not edit text in place — it writes a whole saved snapshot over the editable, rebuilding every text node in the box — so every highlight there dies at that moment: still registered, painting nothing. Only a markup pass re-creates them, and three separate things stopped one from running.

Reproduced against a running Bloom (driving the Edit tab over CDP and inspecting CSS.highlights, checking each Range for collapsed / getClientRects()), with the Leveled Reader tool on a page holding an over-long sentence:

Scenario	Before
Top-bar Undo button	highlight permanently dead (still dead 5.8s later)
Ctrl+Z that restores a range selection (select a word, type over it, undo)	permanently dead
Plain Ctrl+Z	dead for ~550ms, then repainted

Talking Book turned out to be largely self-healing — the MutationObserver added for BL-15300 repairs its current/split highlights in place — so the reader tools were where this showed. Its markup was equally stale after a top-bar Undo, though, since nothing re-ran it.

The three causes:

1. No trigger. The top-bar Undo button produces no keystroke in the page, so the keyup-driven markup update never ran at all. Same for the reader tools' own undo stack.
2. The range-selection guard. selectionStateIsInvalidForMarkup bails when the selection is not collapsed — and an undo restores whatever selection its snapshot was taken with.
3. The longpress flag. jquery.longpress sets isLongPressEvaluating on every keydown and clears it on keyup. Ctrl+Z does its work on the keydown, so an update requested from there always found the flag set and returned.

What changed

One entry point, updateMarkupAfterUndoOrRedo() in toolbox.ts, called from every undo path we own: CKEditor's own undo/redo commands (attachToCkEditor), the top bar's two text-changing branches (handleUndo), and the reader tools' Ctrl+Z/Ctrl+Y interception.

handlePageEditing now takes a trigger ("editing" | "paste" | "undoOrRedo") instead of a retry count. The trigger is what the four undo-specific behaviours hang off: skip the longpress flag, tolerate a range selection, run immediately instead of after the 500ms typing debounce, and wait on its own timer so the keyup that ends Ctrl+Z cannot cancel it.

After

Top-bar Undo, Ctrl+Z, Ctrl+Z-over-a-selection and Ctrl+Y all keep the highlight alive. Sampling every 10ms found it dead only once, for ~18ms (sub-frame), on the reader-model branch. Talking Book unchanged: all four split highlights stay live through both paths.

Not unit-tested, for the reason already recorded in handlePageEditing: exercising it needs a live CKEditor instance on the editable plus the parent window's page iframe and a real Selection, none of which stand up in jsdom. Verified in the running app instead, as above.

Ref: https://issues.bloomlibrary.org/youtrack/issue/BL-16558

Devin review

---

This change is 

This fixes a tester-reported regression on the card

The problem reported in BL-16558 comment 102-75392 — select highlighted text in a decodable reader, delete it, click the top-bar Undo, and all the highlighting is gone until you click outside the box — is exactly the top-bar-Undo path above. That report was against 6.5.1307 Alpha, and it was noted there as a regression from 6.4.107 Beta.

[JohnThomson]

(Claude Opus 5) Consulted Devin on 2026-08-13, up to commit 3c857036a8423478da38dd724b82610a03a2fe83.

Devin reviewed all four commits on this branch as they were pushed. Across those runs it raised one bug and three things to investigate, plus eight informational notes:

• Bug — the two new helpers in handlePageEditing used const foo = () => where src/BloomBrowserUI/AGENTS.md asks for function syntax. Fixed in 3c85703; Devin's final pass confirms it as resolved. Never needed a thread.
• Two independent markup timers mean two markup passes can now overlap — Re-mark up the page after an Undo or Redo (BL-16558) #8201 (comment). Left open for John: part of it is a known limitation recorded in the commit message (on Ctrl+Z with Talking Book open, the keyup discards the undo pass's async result, leaving today's 500ms behaviour).
• Marking up after a reader-model undo can clear the redo stack — Re-mark up the page after an Undo or Redo (BL-16558) #8201 (comment). Left open for John: the mechanism is real but confined to the reader tools' own undo stack, which this card already has a parked question about removing.
• Undo now marks up with a non-collapsed selection, inserting two bookmark spans — Re-mark up the page after an Undo or Redo (BL-16558) #8201 (comment). Checked in a running Bloom: both bookmarks survive and the range selection is restored intact, so this is resolved.
• Two of the informational notes led to fixes anyway (8ff980d and 659c806, both about when the undo throttle records a pass). The rest describe deliberate choices — e.g. that image and origami undo get no markup refresh because they don't rewrite text.

CI (pr-automation) is green. No comment-posting review bot is active on this repo: CodeRabbit is installed but .coderabbit.yml sets auto_review.enabled: false, and no bot has posted on any recent PR here.

[StephenMcConnel]

@StephenMcConnel reviewed 6 files and all commit messages, and resolved 3 discussions.
Reviewable status: complete! all files reviewed, all discussions resolved (waiting on JohnThomson).