Repository navigation
JS debugging: dragging the increment mode number field sometimes jumps at the start #2807
Description
This seems to probably happen more commonly in Chrome, and it seems to be harder to reproduce in Firefox (I wasn't able to reproduce it in FF in my testing right now, @0HyperCube mentions in the comments below that he has encountered it in FF). See NumberInput.svelte.
When you click and drag a number input field of the increment (not range) style, meaning the kind you can drag infinitely left or right, it will sometimes teleport the value to a wildly different value from the one it started with. This can be reproduced by drawing a rectangle and dragging left and right on its stroke weight parameter in the Properties panel repeatedly in quick, small left and right drags until occasionally it will make a big jump.
I hypothesize this is caused by weirdness in the event ordering and mouse position reporting with the pointer lock API, and it might be related to the widget being broken in Safari: #2038. I recommend logging the values that are being reported by the API and current state every frame to narrow down when the events occur and produce the discrepancy.
At the 4-second mark in this video, we see it jump from 131.3 to 17.3 immediately when the click-and-drag begins:
Activity
[-]JS debugging: dragging the increment mode number field sometimes jumps at the start[/-][+]Chrome JS debugging: dragging the increment mode number field sometimes jumps at the start[/+][-]Chrome JS debugging: dragging the increment mode number field sometimes jumps at the start[/-][+]Chrome-specific JS debugging: dragging the increment mode number field sometimes jumps at the start[/+]0HyperCube commentedon Jul 5, 2025
I also sometimes get this on firefox nightly.
[-]Chrome-specific JS debugging: dragging the increment mode number field sometimes jumps at the start[/-][+]JS debugging: dragging the increment mode number field sometimes jumps at the start[/+]Demohstens commentedon Jul 6, 2025
The issue seems to be an underlying issue with how events report mouse movement: https://issues.chromium.org/issues/40547981
A possible fix is to add the following in Line 385 (NumberInput.svelte)
200 is a magic number based on some debugging that reported numbers in the high hundreds. This also still allowed for smooth-feeling input at higher DPIs.
Keavon commentedon Aug 19, 2025
A possible workaround: don't use Pointer Lock while dragging on-screen within the web page area, but switch to Pointer Lock when nearing the edge of the screen (
screenX). Just hide the cursor by setting thehide-cursorclass on thebodyelement during small drags, but we have to be careful to ensure that works when it also goes outside the browser window (this seems to occur automatically while using a drawing tool and dragging with its cursor showing, initially from within the viewport then extending outside the browser).This approach won't work in Safari because it incorrectly implements an old version of the Pointer Lock spec, and as such, it wrongly requires an engagement gesture (which isn't a concept in the modern version of the API that FF and Chrome both implement) to be the originating event, so that includes
mousedownbut notmousemove. But we already can't achieve this in Safari because we have to wait aftermousedownfor the first frame ofmousemoveto know that the user is dragging not clicking on the input field, which is why we're unable to use Pointer Lock on Safari (in addition to the fact that Safari displays its notification at the top of the page by resizing and shifting down the entire page contents which is unacceptably jarring).Anurag-S1ngh commentedon Oct 21, 2026