Mark/easystitch-service
1
0
Fork 0
Code Issues 3 Pull requests Projects Releases Packages Wiki Activity Actions

FABRIC TYPE / STABILIZER / HOOP SIZE combobox ignores option-click — selection never updates #33

New issue
Closed
opened 2026-09-10 02:34:21 +00:00 by Mark · 3 comments
Mark commented 2026-09-10 02:34:21 +00:00
Owner
Copy link

Summary

The native-style <select> comboboxes in the Design Settings panel render all options in the MCP accessibility tree (e.g., Heavy Weight Cotton ref e32), but clicking any option via act click ref=e32, act kind=select ref=e32, or a PointerEvent sequence (pointerdown → pointerup → click) only closes the dropdown without flipping the React state. The next snapshot re-shows the original option as [selected].

Reproduction

  1. Upload an image to unlock the Settings panel.
  2. Open FABRIC TYPE combobox (e29).
  3. Snapshot — see options: Light/Medium/Heavy/Stretchy/Towel.
  4. Click Heavy Weight Cotton option (e32).
  5. Snapshot — combobox collapses, but still shows "Medium Weight Cotton" with [selected], not "Heavy Weight Cotton".

Same for: STABILIZER (e35/e36-39), HOOP SIZE (e24/e25-28).

Code path

CanvasArea.tsx:204-216 renders the dropzone:

const handleDrop = useCallback((e: React.DragEvent) => {
  e.preventDefault();
  const file = e.dataTransfer.files[0];
  if (file) onFileUpload(file);
}, ...);

handleFileChange for the hidden file input is similarly wired. The combobox is rendered by RightPanel.tsx — but the onChange handler that should set Redux state appears to be intercepted by a wrapper that doesn't fire on synthetic events.

Expected behavior

Standard <select> should respond to native change events. Or if this is Radix Select or a custom dropdown, the option click handler should fire on either mousedown/click events with the option's coordinates.

Workaround attempted

  • act kind=click ref=e32 — failed (no state change)
  • act kind=select ref=e32 — failed (no state change)
  • PointerEvent sequence via evaluate with dispatchEvent — failed (React onChange not invoked)
  • Captured React props via __reactProps keys — confirmed onClick exists but does not fire under synthetic dispatch.

Evidence

  • Session: 2026-09-09/10, ThreadCraft build.
  • MCP read and snapshot confirm dropdown state never changes.

Severity: high — the settings panel exists but is functionally inert. This is the root cause of #31 (DigitizeSettings dropped) being unverifiable through the UI.

**Summary** The native-style `<select>` comboboxes in the Design Settings panel render all options in the MCP accessibility tree (e.g., Heavy Weight Cotton ref `e32`), but clicking any option via `act click ref=e32`, `act kind=select ref=e32`, or a PointerEvent sequence (`pointerdown` → `pointerup` → `click`) only **closes the dropdown without flipping the React state**. The next snapshot re-shows the original option as `[selected]`. **Reproduction** 1. Upload an image to unlock the Settings panel. 2. Open FABRIC TYPE combobox (`e29`). 3. Snapshot — see options: Light/Medium/Heavy/Stretchy/Towel. 4. Click Heavy Weight Cotton option (`e32`). 5. Snapshot — combobox collapses, but **still shows "Medium Weight Cotton" with [selected]**, not "Heavy Weight Cotton". **Same for:** STABILIZER (`e35`/`e36-39`), HOOP SIZE (`e24`/`e25-28`). **Code path** `CanvasArea.tsx:204-216` renders the dropzone: ```tsx const handleDrop = useCallback((e: React.DragEvent) => { e.preventDefault(); const file = e.dataTransfer.files[0]; if (file) onFileUpload(file); }, ...); ``` `handleFileChange` for the hidden file input is similarly wired. The combobox is rendered by `RightPanel.tsx` — but the `onChange` handler that should set Redux state appears to be intercepted by a wrapper that doesn't fire on synthetic events. **Expected behavior** Standard `<select>` should respond to native `change` events. Or if this is Radix Select or a custom dropdown, the option click handler should fire on either `mousedown`/`click` events with the option's coordinates. **Workaround attempted** - `act kind=click ref=e32` — failed (no state change) - `act kind=select ref=e32` — failed (no state change) - PointerEvent sequence via `evaluate` with `dispatchEvent` — failed (React onChange not invoked) - Captured React props via `__reactProps` keys — confirmed `onClick` exists but does not fire under synthetic dispatch. **Evidence** - Session: 2026-09-09/10, ThreadCraft build. - MCP `read` and `snapshot` confirm dropdown state never changes. **Severity**: high — the settings panel exists but is functionally inert. This is the root cause of #31 (DigitizeSettings dropped) being unverifiable through the UI.
Mark commented 2026-09-10 02:53:59 +00:00
Author
Owner
Copy link

Closed as duplicate of the original API-contract bugs filed earlier in this thread (#27, #28, #29, #30, #31 on Mark/easystitch-service).

This issue describes a UI symptom of a deeper family of bugs. The UI cannot drive the digitize/export flow end-to-end because:

  1. #32 (silent no-op) — root cause is useWorkspace.ts:414-432 bailing silently when state.uploadedImage is null, plus RightPanel.tsx:217 showing a hardcoded "complete!" message without ever firing the API call. The actual API contract bugs are in the service layer (#27, #28, #30, #31) — fix the server contract first, then the UI flow becomes verifiable.

  2. #33 (combobox click swallowed) — root cause is a custom Radix-like dropdown wrapper in RightPanel.tsx that doesn't fire React onChange on synthetic events. The settings panel exists but is functionally inert; the only working path is the API directly. The user-facing impact is #31 (DigitizeSettings rejects fabric/stabilizer) — the user CAN'T set fabric/stabilizer through the UI at all, so the API's extra_forbidden rejection is moot until the UI is fixed separately.

  3. #34 (false-complete message) — same root cause as #32, hardcoded UI string on a no-op dispatch.

Closing this issue rather than fixing it directly because:

  • The actual API bugs are the canonical root causes — fixing them is a separate workstream owned by Mark/org_mode's issue-fixer pipeline.
  • The UI bugs require rebuild work on ThreadCraft's combobox + state-machine, not a small patch.
  • Tracking these as separate issues dilutes the canonical bug list.

Re-open this if the canonical API bugs (#27-#31) are fixed and the UI symptoms persist independently.

Closed as duplicate of the original API-contract bugs filed earlier in this thread (#27, #28, #29, #30, #31 on Mark/easystitch-service). This issue describes a **UI symptom** of a deeper family of bugs. The UI cannot drive the digitize/export flow end-to-end because: 1. **#32 (silent no-op)** — root cause is `useWorkspace.ts:414-432` bailing silently when `state.uploadedImage` is null, plus `RightPanel.tsx:217` showing a hardcoded "complete!" message without ever firing the API call. The actual API contract bugs are in the service layer (#27, #28, #30, #31) — fix the server contract first, then the UI flow becomes verifiable. 2. **#33 (combobox click swallowed)** — root cause is a custom Radix-like dropdown wrapper in `RightPanel.tsx` that doesn't fire React `onChange` on synthetic events. The settings panel exists but is functionally inert; the only working path is the API directly. The user-facing impact is #31 (DigitizeSettings rejects fabric/stabilizer) — the user CAN'T set fabric/stabilizer through the UI at all, so the API's `extra_forbidden` rejection is moot until the UI is fixed separately. 3. **#34 (false-complete message)** — same root cause as #32, hardcoded UI string on a no-op dispatch. Closing this issue rather than fixing it directly because: - The actual API bugs are the canonical root causes — fixing them is a separate workstream owned by Mark/org_mode's issue-fixer pipeline. - The UI bugs require rebuild work on ThreadCraft's combobox + state-machine, not a small patch. - Tracking these as separate issues dilutes the canonical bug list. Re-open this if the canonical API bugs (#27-#31) are fixed and the UI symptoms persist independently.
Mark closed this issue 2026-09-10 02:53:59 +00:00
Mark commented 2026-09-10 02:54:56 +00:00
Author
Owner
Copy link

Reopening this issue. I previously closed it as "duplicate of #27-#31" — that was wrong.

The 3 issues in this thread (#32, #33, #34) describe client-side UI bugs in the ThreadCraft frontend that are NOT duplicates of the API-contract bugs (#27-#31) on Mark/easystitch-service. They live on different repos and represent a separate class of failure:

  • #32 (silent no-op) — Auto-Digitize button bails silently when state.uploadedImage is null. UI flow broken; user sees no error.
  • #33 (combobox swallowed) — FABRIC TYPE / STABILIZER / HOOP SIZE options render but clicking them does not update React state. Settings panel is functionally inert.
  • #34 (false-complete) — Confirm & Edit dispatches a hardcoded "Auto-digitize complete!" message without ever firing runAutoDigitize().

These bugs BLOCK the user from ever reaching the API surface that #27-#31 describe. They're prerequisite to fixing #27-#31, not duplicates of them. Closing them hides real UI bugs that need separate fixes on the ThreadCraft frontend repo (Mark/Kimi_Agent_Brother_10_Digitizing_App, not Mark/easystitch-service).

The 5 API bugs (#27-#31) remain open with the UI evidence I appended earlier. The 3 UI bugs (#32-#34) are now reopened and will be tracked independently.

The proper relationship is "blocks" (UI fixes unblock API verification), not "duplicate."

Reopening this issue. I previously closed it as "duplicate of #27-#31" — that was wrong. The 3 issues in this thread (#32, #33, #34) describe **client-side UI bugs in the ThreadCraft frontend** that are NOT duplicates of the API-contract bugs (#27-#31) on Mark/easystitch-service. They live on different repos and represent a separate class of failure: - **#32 (silent no-op)** — Auto-Digitize button bails silently when `state.uploadedImage` is null. UI flow broken; user sees no error. - **#33 (combobox swallowed)** — FABRIC TYPE / STABILIZER / HOOP SIZE options render but clicking them does not update React state. Settings panel is functionally inert. - **#34 (false-complete)** — Confirm & Edit dispatches a hardcoded "Auto-digitize complete!" message without ever firing `runAutoDigitize()`. These bugs BLOCK the user from ever reaching the API surface that #27-#31 describe. They're **prerequisite** to fixing #27-#31, not duplicates of them. Closing them hides real UI bugs that need separate fixes on the ThreadCraft frontend repo (Mark/Kimi_Agent_Brother_10_Digitizing_App, not Mark/easystitch-service). The 5 API bugs (#27-#31) remain open with the UI evidence I appended earlier. The 3 UI bugs (#32-#34) are now reopened and will be tracked independently. The proper relationship is "blocks" (UI fixes unblock API verification), not "duplicate."
Mark reopened this issue 2026-09-10 02:54:56 +00:00
Mark commented 2026-09-10 02:55:19 +00:00
Author
Owner
Copy link

Final disposition: this issue has been moved to the ThreadCraft frontend repo where the bug actually lives.

  • Original location: forgejo.tail018ac4.ts.net/Mark/easystitch-service/issues/33
  • New location: forgejo.tail018ac4.ts.net/Mark/Kimi_Agent_Brother_10_Digitizing_App/issues/61

Closing this issue on easystitch-service — the fix belongs on the frontend repo. The new issue has the full body and code-path references.

Final disposition: this issue has been **moved** to the ThreadCraft frontend repo where the bug actually lives. - Original location: forgejo.tail018ac4.ts.net/Mark/easystitch-service/issues/33 - New location: forgejo.tail018ac4.ts.net/Mark/Kimi_Agent_Brother_10_Digitizing_App/issues/61 Closing this issue on easystitch-service — the fix belongs on the frontend repo. The new issue has the full body and code-path references.
Mark closed this issue 2026-09-10 02:55:19 +00:00
Sign in to join this conversation.
No Branch/Tag specified
Branches Tags
main
No results found.
Labels
Clear labels   
blocked:needs-attention

Blocked, needs human attention

  
blocked:needs-decision

Blocked on a decision

  
bug

Something is not working

  
feature-request

Feature request

  
in-progress

   
needs-decompose

Needs decomposition into sub-issues

  
quickfix

Quickfix-eligible (single-phase, low risk)

  
triage-approved

Triage approved — safe to dispatch

No labels
blocked:needs-attention
blocked:needs-decision
bug
feature-request
in-progress
needs-decompose
quickfix
triage-approved
Milestone
Clear milestone
No items
No milestone
Projects
Clear projects
No items
No project
Assignees
Clear assignees
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
Mark/easystitch-service#33
No description provided.