Refactor canvas elements: registry-driven controls

.claude/CLAUDE.md

@@ -0,0 +1,6 @@
+# Project Memory
+
+Instructions here apply to this project and are shared with team members.
+
+## Context
+

.github/prompts/bloom-uitest.prompt.md → .github/prompts/bloom-component-test.prompt.md

@@ -1,5 +1,4 @@
 ---
-mode: agent
 description: setup ui tests
 ---
 We have a test system explained at src/BloomBrowserUI/react_components/component-tester/README.md.
@@ -21,6 +20,6 @@ Sometimes the top level component is not readily testable. In that case it might
 ## Guidelines for writing the tests
 * If you want to make a mock, stop and ask me.
 * Avoid using timed waits like page.waitForTimeout(1000). If there is no other way, you must discuss it with me first and then if I approve, document why it is necessary in a comment.
-* Feel free to add test-id attributes to elements in the component under test to make them easier to find. Avoid using css to finding things.
+* Feel free to add data-test-id attributes to elements in the component under test to make them easier to find. Avoid using css to finding things.
 * Keep the tests well factored with common code going to a test-helpers.ts file.
 

.github/prompts/bloom-l10.prompt.md

@@ -1,5 +1,4 @@
 ---
-mode: agent
 description: make a string localizable
 ---
 

.github/prompts/bloom-make-pr-comment-plan.prompt.md

@@ -0,0 +1,40 @@
+---
+description: create a document to help in process large numbers of pr comments
+---
+1) if I didn't tell you the name of the document, use the askQuestions tool to ask me. Always include the option "append or create pr-comments.md". If there is already a "pr-comments.md", then also offer one with a unique name that we don't have yet, like "pr-comments-2.md". Do this quickly so that I can leave while you work on the rest.
+2) Find the pr. Use the gh tool to determine the PR associated with the current branch.
+3) Collect up comments that do that have a reply. Do not rely only on native GitHub review threads. Also inspect the PR's reviews and review bodies for Reviewable-imported comments or discussion summaries, because those may not appear in `reviewThreads` even when the review says it contains many unresolved comments. Treat those Reviewable comments as part of the PR feedback you need to process.
+
+4) for each issue, add some lines like this:
+
+----------------------
+## Fred Flintstone review 3918647127
+
+### 1. foo should be bar
+
+Link: <https://reviewable.io/reviews/BloomBooks/BloomDesktop/7621#-On-YsWVBDGHZLABoBtc:-On3jl8a-ol2j7BjS4fE:b-nlm6k9>
+Relevant code locations: bedrock.ts, line 52.
+
+What they said:
+| The foo here should be bar, shouldn't it?   <-- verbatim quote. Do not paraphrase.
+
+Evaluation:
+Bar would't be bad, and we can make this change cheaply. The complication is that we already have a bar.
+
+Action Proposals:
+1. Change foo to baz <-- proposed
+2. Change foo to bar2
+3. Say that <this user> prefers to stick with foo.
+
+- Proposed Reply: "[model name]: It turns out "bar" is already in use, so I've changed to "baz". <--- do not be chatty, just state what you did (or would do)
+
+User Decision:  <-- user will fill this in later
+Reply:
+
+- [ ] Reply successfully posted (check off when posted to github or Reviewable):
+
+-------------------
+
+Leave the "decision:" and "reply" lines there for a future step in our process.
+
+When you answer, prefix your response with the name of your model, e.g. [hall9000].

.github/prompts/bloom-open-solution-in-VS.prompt.md

@@ -0,0 +1,7 @@
+---
+description: open Visual Studio with the solution of this workspace
+model: Claude Haiku 4.5
+agent: agent
+---
+
+Open "Visual Studio" with the path to "Bloom.sln" in this workspace.

.github/prompts/bloom-process-pr-comments.prompt.md

@@ -0,0 +1,8 @@
+---
+description: read and process comments in a pr
+---
+
+Use the gh tool to determine the PR associated with the current branch. If you cannot find one, use the askQuestions tool to ask the user for a url.
+Read the unresolved pr comments and either answer them or handle the problem they call out and then answer them.
+Do not rely only on native GitHub review threads. Also inspect the PR's reviews and review bodies for Reviewable-imported comments or discussion summaries, because those may not appear in `reviewThreads` even when the review says it contains many unresolved comments. Treat those Reviewable comments as part of the PR feedback you need to process.
+When you answer, prefix your response with the name of your model, e.g. [hall9000].

.github/prompts/bloom-process-pr-feedback.prompt.md

@@ -4,4 +4,5 @@ description: read and process comments in a pr. Only appropriate to use in the r
 
 Use the gh tool to determine the PR associated with the current branch. If you cannot find one, use the askQuestions tool to ask the user for a url.
 Read the unresolved pr comments and either answer them or handle the problem they call out and then answer them.
+Do not rely only on native GitHub review threads. Also inspect the PR's reviews and review bodies for Reviewable-imported comments or discussion summaries, because those may not appear in `reviewThreads` even when the review says it contains many unresolved comments. Treat those Reviewable comments as part of the PR feedback you need to process.
 When you answer, prefix your response with the name of your model, e.g. [hall9000].

.github/skills/bloom-canvas-e2e-testing/SKILL.md

@@ -0,0 +1,99 @@
+---
+name: bloom-canvas-e2e-testing
+description: build and run automated Playwright end-to-end tests for Canvas Tool behavior on CURRENTPAGE.
+---
+
+## Scope
+Use this skill when the user wants automated Playwright tests (not manual devtools reproduction) for Canvas Tool behavior.
+
+This skill is for:
+- creating and maintaining `bookEdit/canvas-e2e-tests` tests
+- verifying drag/drop and canvas interactions with real mouse gestures
+- running focused Canvas E2E checks against Bloom Edit Tab
+
+This skill is not for:
+- manual-only reproduction (use the manual canvas tool testing skill)
+- component-harness tests under `react_components/*/*.uitest.ts`
+
+## Required context
+- Bloom is running and serving Edit Tab at `http://localhost:8089/bloom/CURRENTPAGE`
+- Current page includes `.bloom-canvas`
+- Canvas tool is available in toolbox
+- Playwright runtime dependencies are installed in:
+  - `src/BloomBrowserUI`
+
+## Primary URL
+- `http://localhost:8089/bloom/CURRENTPAGE`
+
+## Runtime and command model
+Use the `src/BloomBrowserUI` package and run the canvas suite via the root e2e script.
+
+1) Install once (or when deps change):
+- `cd src/BloomBrowserUI`
+- `yarn install`
+
+2) Run one canvas test:
+- `cd src/BloomBrowserUI`
+- `yarn e2e canvas specs/01-toolbox-drag-to-canvas.spec.ts`
+
+3) Run the full canvas suite:
+- `cd src/BloomBrowserUI`
+- `yarn e2e canvas`
+
+## Frame model (critical)
+Bloom Edit Tab has multiple iframes. Use frame names first:
+
+- Toolbox frame:
+  - name: `toolbox`
+  - URL usually includes `toolboxContent`
+- Editable page frame:
+  - name: `page`
+  - URL usually includes `page-memsim-...htm`
+- Do not treat top `CURRENTPAGE` frame as editable page content.
+
+## Reliable selectors and activation
+- Canvas tool tab header: `h3[data-toolid="canvasTool"]`
+- Canvas tool root: `#canvasToolControls`
+- Canvas surface: `.bloom-canvas`
+- Created elements: `.bloom-canvas-element`
+- Speech/comic palette item: `img[src*="comic-icon.svg"]`
+
+Before clicking the canvas tool header, first check whether `#canvasToolControls` is already visible.
+
+## Drag/drop requirements
+- Use real Playwright mouse gestures (`page.mouse.down/move/up`), not synthetic dispatched drag events.
+- Prefer distinct drop points.
+- Verify outcomes semantically:
+  - element count increase (`.bloom-canvas-element`)
+  - position/rect checks where relevant
+
+## Critical safety rule (Image Toolbox)
+- Do **not** run any action that opens the native Image Toolbox window.
+- In Canvas context menus/toolbars, never invoke commands that route to `doImageCommand(..., "change")`.
+- In practice, do not click:
+  - `Choose image from your computer...`
+  - `Change image`
+- Do **not** invoke native video capture/file-picker commands either.
+- In practice, do not click:
+  - `Choose Video from your Computer...`
+  - `Record yourself...`
+- If coverage needs those commands, verify command presence/enabled state only (do not invoke).
+
+## Minimal proof recipe
+A valid non-trivial proof test should:
+1. Open `CURRENTPAGE`
+2. Resolve toolbox + page frames
+3. Ensure Canvas tool active
+4. Drag a palette item onto `.bloom-canvas`
+5. Assert `.bloom-canvas-element` count increased
+
+## Troubleshooting
+- If test says "No tests found": verify path filter is relative to the config `testDir`.
+- If command says `playwright: not found`: run `yarn install` in `src/BloomBrowserUI`.
+- If canvas waits time out: confirm you selected the `page` frame, not top frame.
+- If canvas tab click times out: check whether Canvas controls are already visible and skip click in that case.
+
+
+## Pointers
+- Avoid time-based waiting; use DOM-based checks when possible. Feel free to add data-test-ids attributes or other hooks in the app code if needed for reliable testing.
+

.github/skills/bloom-canvas-tool-testing/SKILL.md

@@ -0,0 +1,39 @@
+---
+name: bloom-canvas-tool-manual-testing
+description: explore, reproduce, and verify Canvas Element behaviors manually via chrome-devtools-mcp, not in a playwright test.
+---
+
+## Scope
+Use this skill when the user reports a regression involving Canvas Tool interactions (especially drag/drop from the toolbox onto the page) and asks you to reproduce and verify fixes using a browser.
+
+This skill assumes:
+- Bloom is running locally and serving the Edit Tab
+- The current page has an element with class `.bloom-canvas`
+- The current page has the Canvas Tool tab available in the toolbox
+- The user has started the vite dev server for the frontend code
+
+## Primary test URL
+  - `http://localhost:8089/bloom/CURRENTPAGE`
+
+## Reproduction approach (required)
+When testing or verifying a UI regression:
+- Do not rely only on synthetic JS event dispatch.
+- Use browser automation/tools to perform an actual drag/drop gesture.
+
+## Finding things
+1. If your task involves the toolbox, identify that the toolbox iframe (often `.../toolboxContent`) and confirm the Canvas Tool tab is selected.
+2. The page we are editing is in an iframe (a `page-memsim-...htm`)
+3. On the page, you can locate the canvas we are editing as an element with the `.bloom-canvas` class.
+
+
+## If you are performing drag/drop
+1. Perform a drag from the toolbox item onto a distinct point on the page (test with multiple drop points).
+2. Verify outcome by measuring:
+   - The intended drop point (clientX/clientY over the page frame)
+   - The created element’s bounding rect and/or `style.left/top`
+   - The delta between drop point and element location
+   - Test with multiple zoom levels and page scaling to confirm consistent behavior
+
+## Notes
+- Bloom’s edit UI uses multiple iframes; coordinate systems (screen/client/page) often differ between frames.
+- Page scaling (`transform: scale(...)`) can affect `getBoundingClientRect()` values; prefer consistent coordinate spaces when comparing.