edemaine / cocreate

Cocreate Shared Whiteboard/Drawing
MIT License
209 stars 27 forks source link

Shift scrollwheel for horizontal scrolling #131

Closed edemaine closed 3 years ago

edemaine commented 3 years ago

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. :-)

duetosymmetry commented 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.

duetosymmetry commented 3 years ago

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?

edemaine commented 3 years ago

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.)

duetosymmetry commented 3 years ago

If you hold down shift while scrolling, do you get events where e.shiftKey is true, and e.deltaX == 0, and e.deltaY != 0 ?

edemaine commented 3 years ago

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.

edemaine commented 3 years ago

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 deltaModes.

Comparing Firefox and Chrome, one line seems to be equal to 50 pixels.

Fixed this part in 3ac6755.

duetosymmetry commented 3 years ago

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.

edemaine commented 3 years ago

@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.