Click to zoom broken on Magic Mouse (and likely other devices with noisy pointer events)

[frontedbe]

Bug description
Clicking an image to zoom does not work when using a Magic Mouse (and likely other devices that emit pointermove events during an otherwise stationary click). Experienced it with 2 different Magic Mouses, but my Macbook Pro trackpad clicks worked fine.

Root cause
In src/components/image.svelte, hasDragged is set based on the number of pointermove events rather than the actual pixel distance traveled:

// line 221
hasDragged = dragPositions.push({ x, y }) > 2

The Magic Mouse fires multiple pointermove events even during a completely stationary click, causing hasDragged to become true and preventing the zoom toggle in onPointerUp:

} else if (!opts.onImageClick?.(container.el, activeItem)) {
    changeZoom($zoomed ? -maxZoom : maxZoom, e) // never reached
}

To reproduce

1. Open a BiggerPicture lightbox on a device with a Magic Mouse (or any mouse that emits pointermove during click)
2. Click the image to zoom
3. Nothing happens — zoom is not triggered
   Debug evidence
   Console output for a single stationary click on Magic Mouse:

⬇ pointerdown  x: 1664.61  y: 839.53
↔ pointermove  x: 1664.48  y: 839.53   // distance: 0.13px
↔ pointermove  x: 1664.38  y: 839.53   // distance: 0.23px
↔ pointermove  x: 1664.23  y: 839.53   // distance: 0.38px
↔ pointermove  x: 1664.09  y: 839.53   // distance: 0.52px
⬆ pointerup    x: 1664.09  y: 839.53

Total movement: 0.52px — clearly a click, not a drag. Yet hasDragged becomes true after 3+ pointermove events.
Expected behavior
hasDragged should be determined by pixel distance rather than event count. A small threshold (e.g. 10px) would correctly distinguish clicks from drags regardless of how many pointermove events the device emits.

Suggested fix

Replace the event-count check with a distance check:

// Instead of:
hasDragged = dragPositions.push({ x, y }) > 2
// Use:
const dist = Math.hypot(e.clientX - dragStartX, e.clientY - dragStartY)
hasDragged = dist > 10

Workaround

Until this is fixed, it's possible to intercept pointermove events in the capture phase and suppress those within a small radius:

const CLICK_THRESHOLD_PX = 10
let startX = 0, startY = 0
const capturePointerDown = (e) => { startX = e.clientX; startY = e.clientY }
const suppressTinyMoves = (e) => {
    if (Math.hypot(e.clientX - startX, e.clientY - startY) < CLICK_THRESHOLD_PX) {
        e.stopPropagation()
    }
}
document.addEventListener('pointerdown', capturePointerDown, { capture: true })
document.addEventListener('pointermove', suppressTinyMoves, { capture: true })
bp.open({
    // ...
    onClose: () => {
        document.removeEventListener('pointerdown', capturePointerDown, { capture: true })
        document.removeEventListener('pointermove', suppressTinyMoves, { capture: true })
    }
})

[henrygd]

Thanks so much for the detailed report!

I added a fix based on what you suggested. I don't have a mouse that can reproduce the problem, so would it be possible for you to test the fix?

Just clone the repo (or pull latest commit), then run npm install and npm run start (or bun, pnpm, etc.).

If not, no worries.

[frontedbe]

Hi Henry, thanks for the update — and also for building this library, should have mentioned that in my original post 😊

I can't test it on my own project right now, but does https://biggerpicture.henrygd.me/ run on 1.1.19? I'm still experiencing the issue there.

[henrygd]

The demo site was not updated, but should be now. Let me know if it works on your side now 👍

[frontedbe]

Works great now, thanks! 🙏

[henrygd]

No problem, thanks for confirming. I released a new version with the fix (1.1.20). Let me know if it still gives you any trouble.

[frontedbe]

Follow-up: 5px threshold still problematic in some setups

Thanks for the fix in 1.1.20 — the distance threshold approach works well.

On the demo site, click-to-zoom now works perfectly with my Magic Mouse. On our production site (using Vite, @vitejs/plugin-legacy, GSAP ScrollTrigger, etc.), we still see the issue. Possible causes include the legacy bundle, ScrollTrigger, or other parts of our setup.

Workaround: We use the capture-phase pattern described above, but with a 10px threshold instead of 5px — that fixes it reliably.

Suggestion: Would you consider increasing the in-library threshold from 5px to 10px? That may work more reliably across different Magic Mice and setups, while still clearly separating clicks from drags.

[henrygd]

Thanks for the update, I'll reopen the issue.

The demo site also uses the 5px threshold, so I'm not sure why it would work there and not somewhere else. However, the dist assets use a slightly customized version of Svelte that saves a few bytes. Maybe this is the problem.

Can you try installing bigger-picture@next? This uses the stock version of Svelte that the demo site uses.

If that doesn't work, we can test raising the threshold to 10px, but I'd like to avoid that if possible because the gap is a bit more noticeable than 5px.