Make scroll-wheel zoom update the design preview scale

[AmyShang-alt]

Summary

Scroll-wheel zoom over the design preview does not update the preview scale at all. The validation was originally checking zoom direction, but the current failure is more basic: wheel-up and Control+wheel-up both leave the preview at 100%.

Expected

Open a design preview at 100% zoom, scroll the wheel upward over the preview, and see the preview scale increase above 100% within one second. Wheel-down should decrease the scale. The toolbar zoom label and preview transform should reflect the new value.

Observed

On the seeded HTML design preview, the toolbar started at 100% with the preview frame measuring 812 x 673 px and transform scale 1. After a wheel-up gesture over the preview, the toolbar still read 100%, the frame still measured 812 x 673 px, and the transform still read scale 1. Holding Control while scrolling upward also left the preview at 100%.

This means the inverted-zoom symptom did not reproduce because wheel zoom did not respond at all.

User impact

Users cannot use scroll-wheel zoom to enlarge or shrink the design preview. The promised direction cannot be correct when the wheel gesture leaves the preview unchanged.

Evidence

• 01-before-wheel-up.webp - Before wheel-up: preview is at 100% baseline scale.
• 02-after-wheel-up.webp - After wheel-up: preview remains at 100%, unchanged.

Local code notes

• apps/web/src/components/FileViewer.tsx has zoom state, previewScale = zoom / 100, and a shared zoom dropdown for file and live artifact previews.
• The preview CSS uses --preview-scale / --preview-user-scale to size and transform the frame.
• A local search found no onWheel handler in FileViewer.tsx that updates preview zoom from wheel input.
• Existing tests cover the shared zoom dropdown and preview scale layout helpers, but not wheel-driven preview zoom.

Auto-surfaced from local release validation; verified against local code paths before filing.

[YOMXXX]

I did a quick code-path check and this lines up with the current FileViewer implementation.

FileViewer has the shared zoom / setZoom state, the toolbar dropdown, and previewScale = zoom / 100, but I don't see a wheel handler on the preview container that updates that state. So this looks like missing wheel-driven preview zoom rather than just an inverted zoom-direction bug.

Likely fix surface:

• add a preview-container wheel handler in apps/web/src/components/FileViewer.tsx for the design preview / live artifact preview path;
• keep the toolbar zoom label as the source of truth by updating the existing zoom state;
• clamp to the existing zoom range/levels so wheel input cannot push the frame into an unsupported scale;
• add a focused test that starts at 100%, sends a wheel-up gesture over the preview, and observes the toolbar/preview scale move above 100%.

No more repro data needed from the reporter; the current evidence is enough to treat this as a real bug.

[lefarcen]

Thanks for digging into the code path, @YOMXXX — this is helpful.

A quick check against the current FileViewer implementation points the same way: the shared zoom state and previewScale = zoom / 100 path are there, but I still don't see wheel input wired into that state on the preview side. So at this point this looks more like missing wheel-driven preview zoom than just an inverted direction bug.

We'll track it with that narrower scope: update the existing zoom state from the preview container, keep the toolbar label as the source of truth, clamp to the supported zoom range, and cover it with a focused wheel interaction test in apps/web/src/components/FileViewer.tsx. The current repro + code-path notes are enough here — no extra reporter data needed right now.

[lefarcen]

Heads-up: PR #3677 is now open to wire wheel events into FileViewers shared zoom state, which matches the current diagnosis here that the preview has no wheel handler and stays stuck at 100%. Keeping this issue open until that PR lands and the fix is verified.

[lefarcen]

Heads-up: PR #3746 is now open for this with the same narrowed diagnosis we've been tracking here — wheel input wasn't wired into the shared preview zoom state, so the design preview stayed stuck at 100% even when the toolbar path existed. This PR is scoped to wiring Ctrl/Cmd + scroll-wheel into that existing zoom state while leaving normal scrolling alone, and we'll keep the issue open until the fix lands and gets verified.

[lefarcen]

Quick follow-up on this, @YOMXXX: your earlier code-path read still matches the fix path we're tracking.

PR #3677 was closed without merging, but PR #3746 is now carrying the same narrowed scope in FileViewer — wiring Ctrl/Cmd + scroll-wheel into the existing shared zoom state, keeping the toolbar label in sync, and leaving normal scrolling alone. We'll keep this issue open until that PR lands and the behavior is verified end-to-end.

[lefarcen]

Heads-up: PR #3753 is now open for the same narrowed fix path we've been tracking here — wiring Ctrl/Cmd + scroll-wheel from the preview iframe back into FileViewer's existing shared zoom state, while leaving the cross-origin host-wrapper fallback in place. Keeping this issue open until that PR lands and the behavior is verified end-to-end.

[lefarcen]

Heads-up: PR #3769 is now open on the same narrowed fix path we've been tracking here — wiring preview-frame wheel input into FileViewer's existing shared zoom state so the toolbar label and preview scale move together instead of staying stuck at 100%.

This one is scoped to adding the wheel handler on the two preview frame containers in apps/web/src/components/FileViewer.tsx, and we'll keep the issue open until that PR lands and the behavior is verified end-to-end.

[xxiaoxiong]

PR #3769 addresses this — adds onWheel handlers to preview frames (both LiveArtifactViewer and HtmlViewer) so scroll-wheel input bumps the zoom level.