mousewheel direction reversed in glut (chrome)

[rsturgell]

I think this is the result of

2ef851b

I'm now getting button=4 for "up" and button=3 for "down". Looks like that change reversed the sign in getMouseWheelDelta but kept the usage the same in library_glut onMouseWheel, so it makes sense that it reversed which button is reported.

[juj]

Apologies for the regression. However, there have been so many changes to this code path and the wheel direction has been reversed already three times, so in order to maintain stability, I don't want to change any code with respect to this, unless it is accompanied by a test case that can be compiled both natively and in the test suite that will expose the problem and prove the correct behavior after fixed. Would you be able to implement a minimal glut test app that shows the problem and add it to the test_interactive.py suite that one can verify the breakage and the fix?

[rsturgell]

Ok, will do.

I THINK the fix is to just re-add the negation of wheelDelta (which you
removed in library_browser.js getMouseWheelDelta), because wheelDelta has
the opposite sense of positive from the other event properties. Do you
remember why you made that change?

Thanks,
Ryan

On Fri, Oct 10, 2014 at 7:27 AM, juj notifications@github.com wrote:

Apologies for the regression. However, there have been so many changes to
this code path and the wheel direction has been reversed already three
times, so in order to maintain stability, I don't want to change any code
with respect to this, unless it is accompanied by a test case that can be
compiled both natively and in the test suite that will expose the problem
and prove the correct behavior after fixed. Would you be able to implement
a minimal glut test app that shows the problem and add it to the
test_interactive.py suite that one can verify the breakage and the fix?

—
Reply to this email directly or view it on GitHub
#2864 (comment).

[juj]

The negation was added due to user bug report that mouse wheel was reversed in SDL by another even earlier commit. If the issue is GLUT only, then flipping the sign in the GLUT code will probably fix this, but let's add a test first so that the behavior is readily verifiable by anyone.

[rsturgell]

Actually it looks like tests/glut_wheelevents already tests this, but the
test is just a bit buggy - it doesn't verify order, it simply checks that
both "up" and "down" events came. However, if you run the tests you can
tell if it passes based on whether both "mouse wheel ... event received"
message are printed.

If I change that test slightly to correctly report failure when the events
come in the wrong order, it passes in ff and fails in chrome.

This is NOT a glut issue, this is a mousewheel event issue in
library_browser.js. Note that in library_html5.js we do invert y for the
mousewheel event to match the wheel event.

I suspect glfw is also broken, though I couldn't get figure out how to
repro because, while tests/glfw.c reports mousewheel changes, they are
never triggered, I think because of the early out in
library_glfs.js:onMouseWheel where it doesn't trigger the event if
!GLFW.active.scrollFunc.

Ryan

On Sat, Oct 11, 2014 at 9:40 AM, juj notifications@github.com wrote:

The negation was added due to user bug report that mouse wheel was
reversed in SDL by another even earlier commit. If the issue is GLUT only,
then flipping the sign in the GLUT code will probably fix this, but let's
add a test first so that the behavior is readily verifiable by anyone.

—
Reply to this email directly or view it on GitHub
#2864 (comment).

[ghost]

Direction still reversed for:
Chromium 39.0.2171.65
Ubuntu 14.04
emscripten 1.27.0
Direction correct for firefox.

[usagi]

It's not only glut problem, I have check the same behavior in glfw3(em-1.29).
// I was fix a like the problem in GLFW2 at #2304 . The problem is regression.

[stale]

This issue has been automatically marked as stale because there has been no activity in the past 2 years. It will be closed automatically if no further activity occurs in the next 7 days. Feel free to re-open at any time if this issue is still relevant.