Closed edemaine closed 3 years ago
Sure, I think I can do this pretty quickly. I can't change the assignment on the issue but I am mentally assigning myself.
I just tested this with a typical scroll wheel on MacOS X in Chrome, Firefox, and Safari. Holding down shift already sends wheel events with a nonzero deltaX instead of deltaY. So, this behavior already works in all browsers where I can test. Have you found a browser where shift+wheel only sets e.deltaY instead of e.deltaX?
Hmm, yes, it's an issue on my desktop setup: Windows 10, Chrome 87, Kensington trackball. Also seems to be a problem on Firefox (which also scrolls really slowly? but maybe that's a trackball + Firefox thing). So I'd guess it's a Windows vs. MacOS thing. (I tried running on MacOS via BrowserStack, and it also has the issue, but something might have gotten lost in translation.)
If you hold down shift while scrolling, do you get events where e.shiftKey is true, and e.deltaX == 0, and e.deltaY != 0 ?
Yes. Technically, e.deltaX === -0
on these events, but -0 === 0
. So maybe checking for e.deltaX == 0 and e.deltaY != 0 and e.shiftKey
would be a good time to swap deltaX and deltaY? Do you get e.shiftKey
on your events where deltaY is zero but deltaX isn't? (If not, we could always just swap deltaX
and deltaY
when shiftKey
is true.)
It might be this Chrome bug I'm experiencing: https://bugs.chromium.org/p/chromium/issues/detail?id=1107648
Notably, shift+wheel works on the jsfiddle in that bug. So maybe it's something we're doing, like e.preventDefault()
... Update: omitting that line doesn't help.
I found (a reason) why Firefox scrolls slowly on my setup: Firefox chooses to send wheel
events with deltaMode == 1
(WheelEvent.DOM_DELTA_LINE
) whereas Chrome chooses deltaMode == 0
(WheelEvent.DOM_DELTA_PIXEL
). We should scale up a chunk for nonzero deltaMode
s.
Comparing Firefox and Chrome, one line seems to be equal to 50 pixels.
Fixed this part in 3ac6755.
Do you get
e.shiftKey
on your events where deltaY is zero but deltaX isn't?
Yes, I do, in each of Chrome, Safari, and Firefox. I see a deltaY of -0 in Chrome and Safari, but 0 in Firefox.
Firefox chooses to send wheel events with deltaMode == 1
Oh, I did not note this attribute. I agree, we should definitely scale it up. I also get deltaMode==1 in Firefox, but not Chrome or Safari.
@duetosymmetry Could you test PR #134 to make sure it doesn't break/change anything on the MacOS side, with regular wheeling, shift-wheel, ctrl-wheeling, and ctrl-shift-wheeling? (I imagine not, given the data you report above, but doesn't hurt to double-check.) On Windows, it now gives me the desired behavior: regular wheel is vertical, shift-wheel is horizontal, ctrl- and ctrl-shift-wheeling zooms.
Today I learned that shift-scrollwheel is a standard way to scroll horizontally for a mouse with a one-dimensional scrollwheel. For example, Google Sheets supports this, or Chrome supports it in a large image.
We should add support for this (and document it) in Cocreate. Should be very easy. @duetosymmetry let me know if you're interested. :-)