Implement WM_MOUSEHWHEEL events....

webkit/glue/webinputevent_win.cc

Index: webkit/glue/webinputevent_win.cc
===================================================================
--- webkit/glue/webinputevent_win.cc	(revision 4871)
+++ webkit/glue/webinputevent_win.cc	(working copy)
@@ -172,22 +172,14 @@
         break;
     }
 
-    // Windows sends the following messages for tilt-wheel events.
-    //  * Tilt a mousewheel (left)
-    //    message == WM_HSCROLL, wparam == SB_LINELEFT (== SB_LINEUP).
-    //  * Tilt a mousewheel (right)
-    //    message == WM_HSCROLL, wparam == SB_LINERIGHT (== SB_LINEDOWN).
-    // To convert these events to the shift + mousewheel ones, we do not only
-    // add a shift but also change the signs of their |wheel_delta| values.
-    if (WM_HSCROLL == message) {

[Peter Kasting, 2008/11/10 19:00:29]

I still don't think this can possibly be the right change.

We're inside a block handling WM_HSCROLL, but we've now removed the shift hack
for WM_HSCROLL.  It seems like only two things are possible:
* We never receive WM_HSCROLL now that we have WM_MOUSEHWEEL support, and all
WM_HSCROLL code can disappear.  This seems unlikely because I thought this code
also got triggered by some trackpad drivers.
* Removing this code was wrong.

We need to know precisely when this code is triggered and be able to test it to
know what should happen; we can't just change it based on theories about what
might be right.  Does anyone have this info?

-      key_state |= MK_SHIFT;
-      wheel_delta = -wheel_delta;
-    }
-
     // Use GetAsyncKeyState for key state since we are synthesizing 
     // the input
     get_key_state = GetAsyncKeyState;
   } else {
+    // TODO(hbono): we should add a new variable which indicates scroll
+    // direction and remove this key_state hack.
+    if (WM_MOUSEHWHEEL == message)
+      key_state |= MK_SHIFT;
 
     global_x = static_cast<short>(LOWORD(lparam));
     global_y = static_cast<short>(HIWORD(lparam));