fix: undo a drag activity on the page you are given, not the one we remembered (BL-13502)

[JohnThomson]

The problem. prepareActivity records where each draggable started, keeping a reference to the element:

positionsToRestore.push({ x: elt.style.left, y: elt.style.top, elt });

undoPrepareActivity(page) then restored through those references, so it put back the page it had prepared whichever page you passed it — and before that stopped whatever was playing and emptied the record. Only the rest of it cleaned the page it was given.

Inside the player that never shows: it only ever undoes the page it prepared. Bloom desktop hands it a detached copy — that is how a toolbox tool takes its markup off the copy of the page being saved, and Bloom now saves whenever the page changes. Two faults came out of that, pulling in opposite directions:

• the live page was put back mid-game, so a tester's every drag undid itself about a quarter of a second later and a drag activity could not be played at all; and
• the copy was not put back, so a save made during play recorded the draggables wherever the tester had left them, overwriting the book's authored start positions.

Both were verified in a running Bloom. Gathering the page while an item was dragged to 333/444 left the live element back at its authored 60/240, and returned content containing class="… bloom-draggedToTarget" style="left: 333px; top: 444px" — which is what would have been written to the book.

The change. Both faults are the same mistake — acting on the remembered elements instead of the page you were given — so they go together. Positions are recorded against the draggable's id and restored by looking that id up in the page passed in, which does the right thing for the prepared page and for a copy of it alike. Stopping playback, and forgetting the record, stay tied to the prepared page: they end the session, and cleaning a copy is not the end of anything.

Nothing changes for the player. ActivityManager.showingPage stops the previous activity before starting the next, so the page being undone is the prepared one and every branch behaves exactly as before. showCorrect and performTryAgain pass the page they already have.

Tests cover both faults and the two ways of getting the fix wrong: undoing a copy restores the copy, undoing a copy leaves the live page's drags alone, undoing the prepared page still restores it, and cleaning a copy does not cost the live page its own restore later. Full suite green: 158 tests.

Found while working on BloomDesktop BL-13502, which is where the copy-of-the-page save comes from. That PR currently works around the first fault by not watching the page while a game is in its Play tab — which does nothing for the second, since an explicit save gathers the page directly. Once this is merged and the dependency bumped, the workaround comes out and both are fixed properly.

🤖 Generated with Claude Code

---

This change is