fix(showcase): tune touch long-press so mobile drags don't trigger page scroll#97
Merged
Conversation
…age scroll On touch the library already gates drag behind a 200ms hold (delayOnTouchOnly default) and cancels the pending drag if the finger moves more than touchStartThreshold (default 5px) before the timer fires. Because touch-action is 'manipulation' while the timer is pending, a cancelled drag falls straight through to a page scroll — so the natural "press and immediately move to drag" motion scrolled the page on iPhone instead of dragging. Apply a shared TOUCH config (delayOnTouchOnly: 150, touchStartThreshold: 15) to every showcase demo: the drag arms faster and tolerates the finger drift of a deliberate drag-start, while a fast scroll flick still exceeds 15px well under 150ms and scrolls as before. Demo-config only; no library change. Co-Authored-By: Claude Opus 4.8 (1M context) <[email protected]>
Dependency Review✅ No vulnerabilities or license issues or OpenSSF Scorecard issues found.Scanned FilesNone |
There was a problem hiding this comment.
Pull request overview
This PR adjusts the showcase demo’s touch interaction configuration to reduce accidental page scrolling on mobile (notably iOS Safari) when users intend to drag items. It does this by introducing a shared touch-tuning options object and applying it consistently to all Sortable instances created in the showcase script.
Changes:
- Introduces a shared
TOUCHoptions object (delayOnTouchOnly: 150,touchStartThreshold: 15) in the demo script. - Applies
...TOUCHto each showcaseSortableinitialization (including shared option objects like Kanban and folder/file lists).
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Problem
Reported while testing the live demo (
/demo/) on an iPhone: the page often scrolls when trying to drag an item.Root cause
On touch, the library already gates drag start behind a long-press:
delayOnTouchOnlydefaults to 200ms andtouchStartThresholddefaults to 5px (DragManager.ts:198-199). While that hold timer is pending,touch-actionis set tomanipulation(scroll allowed), andonPointerMoveBeforeDragcancels the pending drag the instant the finger moves more than 5px (DragManager.ts:909).So the natural "press and immediately move to drag" motion blows past 5px well before the 200ms elapses → the pending drag is cancelled → the gesture falls through to a page scroll. Note that
preventDefault()on pointer events cannot suppress scrolling; onlytouch-action/ non-passivetouchmovecan — so the cancel path scrolls unavoidably.Fix
Apply a shared
TOUCHconfig to every showcase demo:Demo-config only — no library code changed, so no impact on the e2e suite or library consumers.
Verification
npm run check— 0 errors.vite build --config vite.config.examples.ts— demo builds clean (validates the inline module JS).touch-actiontiming can't be faithfully emulated headlessly, so final feel should be confirmed on a real device.Follow-up worth considering
The library default of
delayOnTouchOnly: 200/touchStartThreshold: 5is the same trap for any consumer who doesn't override it. Worth revisiting the default (and/or adding a non-passivetouchmoveguard for immediate-drag mode) in a separate library-level change.🤖 Generated with Claude Code