Zero touch / mobile handlers in the codebase despite Tailwind responsive classes — gallery cards, editor canvas, and workspace canvas are mouse-only #167

New issue

Open

opened 2026-10-03 17:30:28 +00:00 by Mark · 0 comments

Mark commented

2026-10-03 17:30:28 +00:00

Owner

Finding

grep -rn 'onTouchStart\|onTouchMove\|onTouchEnd\|touchstart' src/ returns zero matches. The app has no touch event handlers anywhere.

The Layout, Navbar, and various components use Tailwind responsive classes (md:flex, md:hidden, sm:grid-cols-2, lg:grid-cols-4). The visual layout adapts to mobile screen sizes. But:

The Gallery's DesignCard (src/components/gallery/DesignCard.tsx) has no onTouchStart for long-press menus. The actions menu requires a mouse click.
The Editor's EditorCanvas (src/components/editor/EditorCanvas.tsx) has only onMouseDown/onMouseMove/onMouseUp/onWheel. Drawing paths on a touch device is impossible.
The Workspace's CanvasArea has only mouse handlers. Pan/zoom on touch is impossible.
The RightPanel's slider fields (SliderField) likely don't respond to touch — needs verification, but the standard Slider component is used; the radix/shadcn default has touch support, but the custom SliderField may not.

A user on a tablet or a phone sees the responsive layout but cannot use it. The app is desktop-only by implementation, but the responsive CSS makes it look mobile-compatible.

Where

All mouse-only event handlers: src/components/editor/EditorCanvas.tsx, src/components/workspace/CanvasArea.tsx, src/components/gallery/DesignCard.tsx
Responsive CSS: src/components/Layout.tsx, src/components/Navbar.tsx (mobile menu uses a click toggle, which works on touch but no swipe gestures)
No touch handlers: anywhere in src/

Suggested fix shape

Two scopes:

Document the desktop-only status. The Home page, Help page, or Settings modal should say "ThreadCraft is currently optimized for desktop use. Tablet and mobile support is on the roadmap." A user on a phone sees the message instead of trying to use the app and getting stuck.
Or: add pointer event handlers. Replace onMouseDown/onMouseUp/onMouseMove with onPointerDown/onPointerUp/onPointerMove (which handle both mouse and touch). The pointer events have a unified API; the conversion is mechanical. The Editor's path draw, the Workspace's pan/zoom, and the Gallery's drag-and-drop all benefit.

Option 2 is the right product move. Pointer events have been the standard since 2018; the codebase predates the conversion but the change is straightforward. The Editor's drawing experience on a stylus-enabled tablet (a real use case for design work) is a meaningful product win.

Severity

Medium. Users on tablets or 2-in-1 devices get a broken experience. The app looks responsive but isn't.

Discovered by

Gap analysis (2026-10-02) of input modalities.

The Home page is responsive but the design canvas isn't. Same shape as the Marketing screenshot (#105, fixed) where visual fidelity exceeded implementation.

## Finding `grep -rn 'onTouchStart\|onTouchMove\|onTouchEnd\|touchstart' src/` returns **zero matches**. The app has no touch event handlers anywhere. The Layout, Navbar, and various components use Tailwind responsive classes (`md:flex`, `md:hidden`, `sm:grid-cols-2`, `lg:grid-cols-4`). The visual layout adapts to mobile screen sizes. But: - The Gallery's `DesignCard` (`src/components/gallery/DesignCard.tsx`) has no `onTouchStart` for long-press menus. The actions menu requires a mouse click. - The Editor's `EditorCanvas` (`src/components/editor/EditorCanvas.tsx`) has only `onMouseDown`/`onMouseMove`/`onMouseUp`/`onWheel`. Drawing paths on a touch device is impossible. - The Workspace's `CanvasArea` has only mouse handlers. Pan/zoom on touch is impossible. - The `RightPanel`'s slider fields (`SliderField`) likely don't respond to touch — needs verification, but the standard `Slider` component is used; the radix/shadcn default has touch support, but the custom SliderField may not. A user on a tablet or a phone sees the responsive layout but cannot use it. The app is desktop-only by implementation, but the responsive CSS makes it look mobile-compatible. ## Where - All mouse-only event handlers: `src/components/editor/EditorCanvas.tsx`, `src/components/workspace/CanvasArea.tsx`, `src/components/gallery/DesignCard.tsx` - Responsive CSS: `src/components/Layout.tsx`, `src/components/Navbar.tsx` (mobile menu uses a click toggle, which works on touch but no swipe gestures) - No touch handlers: anywhere in `src/` ## Suggested fix shape Two scopes: 1. **Document the desktop-only status.** The Home page, Help page, or Settings modal should say "ThreadCraft is currently optimized for desktop use. Tablet and mobile support is on the roadmap." A user on a phone sees the message instead of trying to use the app and getting stuck. 2. **Or: add pointer event handlers.** Replace `onMouseDown`/`onMouseUp`/`onMouseMove` with `onPointerDown`/`onPointerUp`/`onPointerMove` (which handle both mouse and touch). The `pointer` events have a unified API; the conversion is mechanical. The Editor's path draw, the Workspace's pan/zoom, and the Gallery's drag-and-drop all benefit. Option 2 is the right product move. Pointer events have been the standard since 2018; the codebase predates the conversion but the change is straightforward. The Editor's drawing experience on a stylus-enabled tablet (a real use case for design work) is a meaningful product win. ## Severity Medium. Users on tablets or 2-in-1 devices get a broken experience. The app looks responsive but isn't. ## Discovered by Gap analysis (2026-10-02) of input modalities. ## Related - The Home page is responsive but the design canvas isn't. Same shape as the Marketing screenshot (#105, fixed) where visual fidelity exceeded implementation.