Safari-specific JS debugging: Click-and-drag number fields can't be released

[peterawhittaker]

1. Make a new document.
2. Draw a circle.
3. In properties panel, click-and-drag to adjust line weight (or any other similar parameter).
4. Value changes as you move mouse left and right; but it's impossible to finish the adjustment; no matter if I click elsewhere, hit Escape, return, hide the panel etc. the value keeps being adjusted as I move my mouse left and right.
5. Have to reload the editor to fix it.

Not shown in the attached video, but this happens with the document zoom value field as well. If I click-and-drag (not just click) in multiple value fields, they all start adjusting up-down!

https://github.com/user-attachments/assets/12cad083-3a4b-4c4e-b105-555af108ea64

I'm running safari Version 18.0 (19619.1.26.111.10, 19619).

[Keavon]

Thanks for this report. This seems to be a Safari bug, or at least an incompatibility with the web spec. I will open this up for the community to help with a Safari fix. See the file NumberInput.svelte to get started. And see also: #2807.

[sm17p]

Can confirm for Safari Version 18.3.1. However, I was able to finish the adjustment once I clicked on the document or layers panel

[celyk]

It doesn't seem to affect ranged sliders, only infinite sliders. E.g Transform rotation which ranges from -180 to 180 degrees and doesn't get stuck to the mouse

[Keavon]

Yeah, they are implemented differently and the infinite sliders use pointer lock.

[celyk]

You should implement a fallback that uses the mouse position without capturing the mouse.

Somehow the pointer lock works fine in these demos https://codepen.io/kesmet/pen/JjGWeQB https://aristocrates.github.io/pointer-lock-demo/

So it's possible, but I have to say not a great experience on Safari. A banner appears at the top that shifts the whole page down. I wouldn't enjoy that happening every time I use a slider

[Keavon]

That would not work well, and is not necessary compared to just fixing the actual bug. It's most likely not impossible in Safari so a fallback with degraded functionality wouldn't be necessitated by a complete lack of browser support.

[seabeeberry]

hey! I found a solution and will create a PR in a moment :) it works for Firefox Nightly as well.

[seabeeberry]

For the last PR, I had put the target.requestPointerLock(); immediately inside the onDragPointerDown function which made dragging possible for Safari but crashed the possibility of text input within the number fields. The current solution I've found which both fixes the dragging issues for Safari and keeps the text input possibility the same as before is moving the target.requestPointerLock(); to the event handler definition onMove:

This seems to work reliably on Safari, Firefox and Chrome. @Keavon if this seems like a good solution to you, I can create the PR!

[seabeeberry]

Unfortunately, the above change did not work consistently. When testing again today I did not observe the same behavior as I did when creating the PR. Maybe the requestPointerLock is highly timing-sensitive on Safari, maybe it was a mistake on my end.

As I don't have any ideas for a solution at this moment, I should be de-assigned from this issue. Hoping someone else has a better idea!