Conversation
The shift branch panned by e.deltaY, but Chrome translates shift + wheel into deltaX and reports deltaY as 0. Adding 0 to pan.x meant the diagram did not move at all. Firefox keeps the value on deltaY with shiftKey set, so both have to be read. Taking deltaX whenever it is non-zero also makes a trackpad's horizontal gesture and a tilt wheel pan the canvas, which send deltaX with no modifier and previously fell through to the vertical branch, where deltaY is 0 — so those did nothing either. Refs drawdb-io#1108.
|
@ntdatt812 is attempting to deploy a commit to the dottle's projects Team on Vercel. A member of the Team first needs to authorize it. |
This branch has not been deployed
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
1 participant
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.
Fixes #1108.
Why nothing moved
The wheel handler's shift branch pans by
e.deltaY:But Chrome does the shift translation itself: with Shift held it reports the scroll on
deltaXand leavesdeltaYat0. So the branch was entered and then added zero, which is exactly the reported symptom — the diagram does not move, rather than moving the wrong way. Firefox keeps the value ondeltaYwithshiftKeyset, which is why this looks browser-specific.Both are now read:
deltaXwhen it carries the scroll,deltaYotherwise.A second case it picks up
The condition also admits
e.deltaX !== 0without a modifier. A trackpad's two-finger horizontal gesture and a tilt wheel send exactly that, and they used to fall through to the finalelse, which pans vertically bydeltaY— also0on a purely horizontal event. So those did nothing either, for the same reason. It is the same defect through a different door, so I fixed it in the same condition rather than leaving a dead path next to the one being fixed. Happy to split it out if you would rather keep the PR to the reported case.Vertical scrolling and ctrl/cmd zoom are untouched.
Verification
npx eslint src/components/EditorCanvas/Canvas.jsx→ No issues found. The repo has no test runner (dev,build,lint,previewonly), so there is nothing to add a regression test to.I have not run the app to confirm the behaviour, and I would rather say so than present results I did not observe. The reasoning is from the handler and the
WheelEventcontract: Chrome setsdeltaXand zeroesdeltaYfor shift + wheel, which makes the existing branch an addition of zero — and that matches the reported symptom exactly.What a reviewer should see on the canvas: