Skip to content

fix(ui-core): the browser's native image drag is impossible on every asset surface - #435

Merged
JArmandoAnaya merged 1 commit into
mainfrom
fix/image-drag
Aug 8, 2026
Merged

fix(ui-core): the browser's native image drag is impossible on every asset surface#435
JArmandoAnaya merged 1 commit into
mainfrom
fix/image-drag

Conversation

@JArmandoAnaya

Copy link
Copy Markdown
Contributor

Closes #428

What changed

The browser's native image drag is now impossible on every asset surface, in both modes.

What the render paths actually are — checked, not assumed: the workspace draws the asset as an <img> inside the stage (there is no canvas-drawn path), and product-wide exactly two <img> elements exist — that canvas image, and AssetThumbnail, which the frame-gallery overlay puts inside the workspace and the batch gallery uses for its tiles.

  • The canvas image was already inertdraggable={false}, pointerEvents: "none" and userSelect: "none" since the adapter's first commit — so it could not be dragged at HEAD; it gains the chromium tests that hold that true.
  • AssetThumbnail was the open surface: its <img> carried no protection, so a drag on a frame-gallery tile (or a batch-gallery tile) lifted a ghost of the picture. It gains draggable={false} — the attribute alone, because an <img draggable={false}> starts no native drag in any engine this product supports, and a second guard behind it would be an untestable double (the AnnotatorPanel precedent).

The e2e stub now gives assets a thumbnail_hash and serves /thumbnail, so the overlay renders real <img> tiles for the test to attack.

Test plan

Both in chromium, with a capture-phase dragstart counter armed before any gesture:

  • "no drag lifts the picture, and the tool's own gesture survives the attempt" — a slow full-width drag across the canvas image with the select tool, then a drag on a frame-gallery thumbnail, both counting zero native drags; then an ordinary bbox draw lands, proving the interaction state came through untouched.
  • "the read-only mode is no more draggable than the editor" — the same canvas drag on a completed batch.

Harness verification: putting draggable={true} on the thumbnail (the explicit spelling of HEAD's default) turns the first test red — which both proves the counter genuinely observes native drag machinery and is the red-at-HEAD demonstration, since HEAD shipped exactly that state. Reverted by its exact diff; tree byte-identical to the commit.

Gate stages (staged; exit codes verbatim):

Stage Exit
uv run pytest -q (green except the ten ffmpeg-environment tests recorded on #429) 0
uv run ruff check . / uv run ruff format --check . 0 / 0
uv run mypy src/visionset / uv run lint-imports 0 / 0
pnpm -r build / pnpm test / pnpm -r lint 0 / 0 / 0
openapi drift / generated client drift / mcp reference drift / version sync 0 / 0 / 0 / 0
browser e2e (CI=1 playwright test, 230 tests) 0
browser cycle (CI=1 playwright test -c playwright.cycle.config.ts) 0

@JArmandoAnaya
JArmandoAnaya merged commit 5eab0e4 into main Aug 8, 2026
13 checks passed
@JArmandoAnaya
JArmandoAnaya deleted the fix/image-drag branch August 8, 2026 10:10
JArmandoAnaya added a commit that referenced this pull request Aug 21, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Annotation canvas: native browser image drag must be impossible

1 participant