Stop offering Bloom Games target images to the AI image editor (BL-16793) - #8337
Conversation
…793) A game target holds a clone of its draggable's content -- image container and <img> included -- so every target looked like another editable image slot. A page with a background plus three draggables offered seven images instead of four, and editing a clone achieved nothing: Bloom rebuilds a target's content from its draggable, so the edit was overwritten. EnumerateBookImages now declines any slot inside [data-target-of]. The filtering deliberately does NOT go in SelectImageSlotsOnPage: a slot's identity is its index in that unfiltered list, and both slotIndexOnPage in the page frame and applyAiImageEditorReplacements re-derive that index, so a slot we decline still has to keep its ordinal. Because the clones are no longer editable, nothing else would repoint one when an AI edit replaces a draggable's image on a page the user does not have open; the target would go on showing the replaced picture, and its reference to the old file also stopped DeleteSupersededAiImageFiles reclaiming it. TryApplyReplacement now repoints those copies. The currently-edited page needs no such work: making the swapped slot the active canvas element -- which applyAiImageEditorReplacements already does so Ctrl+Z can offer the undo -- is what makes Bloom rebuild the clone. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
…(BL-16793) GetGameTargetImageCopiesOfSlot returned every image slot inside a matching target, and TryApplyReplacement repoints all of them at the one replacement. A draggable holding two pictures therefore had BOTH its target copies repointed at whichever picture the user edited, so the other copy showed the wrong picture. Nothing Bloom ships builds a draggable with two pictures, so this was latent rather than reachable -- but copyContentToTarget copies a whole bloom-canvas when it finds one, which is exactly that shape, so leaving the pairing to "there is only ever one" was not safe. Now the slot's position within its draggable selects the copy at the same position within each target, which is sound because a target's content is a copy of the draggable's. Found by Devin's review of PR #8337. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
|
[Claude Opus 5 from Steve McConnel's machine during preflight] Consulted Devin on 2026-09-09 22:16 UTC, up to commit It raised one thing, on the first commit: a draggable holding more than one picture would have had Nothing else: no flags to investigate and no informational items. CI is green, and CodeRabbit's |
andrew-polk
left a comment
andrew-polk
left a comment
There was a problem hiding this comment.
@andrew-polk reviewed 4 files and all commit messages, and resolved 1 discussion.
Reviewable status:complete! all files reviewed, all discussions resolved (waiting on StephenMcConnel).
2 participants
A Bloom Games target holds a clone of its draggable's content — image container and
<img>included — so every target looked to the AI image editor like another editable image slot. The
card's page, with a background plus three draggables, offered seven images instead of four. And
editing a clone achieved nothing: Bloom rebuilds a target's content from its draggable, so the
edit was overwritten.
EnumerateBookImagesnow declines any slot inside[data-target-of].The filtering deliberately does not go in
SelectImageSlotsOnPage: a slot's identity is itsindex in that unfiltered list, and both
slotIndexOnPage(page frame) andapplyAiImageEditorReplacementsre-derive that index, so a slot we decline still has to keep itsordinal. Live check on the Games "Drag Images to Targets" page: the editor is now offered ordinals
0, 3, 5, 7— background plus three draggables — with4, 6, 8(the clones) held open but notoffered.
Because the clones are no longer editable, nothing else would repoint one when an AI edit replaces
a draggable's image on a page the user does not have open: the target would go on showing the
replaced picture, and its stale reference to the old file also stopped
DeleteSupersededAiImageFilesfrom reclaiming it.TryApplyReplacementnow repoints those copies.The currently-edited page needs no such work — making the swapped slot the active canvas element,
which
applyAiImageEditorReplacementsalready does so Ctrl+Z can offer the undo, is what makesBloom rebuild the clone. That was verified by A/B against a running Bloom rather than assumed.
Verified against a running Bloom on a real game book, as well as by unit tests: the offered list,
the ordinal agreement between the two sides, the label renumbering, and an off-page commit
repointing both the draggable and its target's copy.
Ref: https://issues.bloomlibrary.org/youtrack/issue/BL-16793
Devin review
This change is