Browser inconsistencies in scrollY because deltaMode not used calculate wheelEvent deltas

[thomasballinger]

Part of the solution to https://github.com/emscripten-core/emscripten/issues/6283 appears to be to use wheelEvent->deltaMode in Emscripten_HandleWheel to calculate the deltaY.

The conversions used in a fix for libraries using library_browser.js instead of library_html5.js are:

case 0:
  // DOM_DELTA_PIXEL: 100 pixels make up a step
  delta /= 100;
  break;
case 1:
  // DOM_DELTA_LINE: 3 lines make up a step
  delta /= 3;
  break;
case 2:
  // DOM_DELTA_PAGE: A page makes up 80 steps
  delta *= 80;
  break;

Does adding this logic here make sense, should I prep a PR?

[kripken]

I think that makes sense, yes - PR would be great.

Testing might be the hard part, but at least we can test it manually.

[thomasballinger]

https://github.com/emscripten-ports/SDL2/pull/154 has been approved, are there any next steps I can help with here?

[kripken]

Next steps after landing that PR are probably to update the port in emscripten to the commit after that PR landed.

[andrewevstyukhin]

Hi, I wonder the reasons of the existing solution's asymmetry - why divide deltaY but not both (deltaX, deltaY) ?

https://developer.mozilla.org/en-US/docs/Web/API/WheelEvent

WheelEvent.deltaMode Returns an unsigned long representing the unit of the delta* values' scroll amount.

[thomasballinger]

No reason not to for me, this patch fixes the behavior of scrolling I didn't like which was vertical. Matching this for x sounds like a good idea if horizontal scroll sensitivity also feels bad.