Fix wheel event dispatch logic to fallback to document when hit-test fails

Source/core/input/EventHandler.cpp

Index: Source/core/input/EventHandler.cpp
diff --git a/Source/core/input/EventHandler.cpp b/Source/core/input/EventHandler.cpp
index 19698b6bf5a0b587896378adc6a5058273c8515d..f53f4f681e96c0d799d000ce5747a4f6133984ac 100644
--- a/Source/core/input/EventHandler.cpp
+++ b/Source/core/input/EventHandler.cpp
@@ -1762,11 +1762,14 @@ bool EventHandler::handleWheelEvent(const PlatformWheelEvent& event)
             if (widget && passWheelEventToWidget(event, *widget))
                 RETURN_WHEEL_EVENT_HANDLED();
         }
-
-        if (node && !node->dispatchWheelEvent(event))
-            RETURN_WHEEL_EVENT_HANDLED();
+    } else {
+        // Dispatch the event to document if hit-test is empty
+        node = m_frame->document();

[Rick Byers, 2015/06/26 12:34:49]

How did you decide to fall back to 'document' vs. 'window'?  Ideally this
wouldn't be different for different types of events.  Eg. what do touch events
do?  Any idea how other browsers behave?  I assume this isn't spec'd, right?

[majidvp, 2015/06/29 16:58:40]

Hit test falls back to document for clicks and touch events. The code for that
lives in |DeprecatedPaintLayer::hitTest| as a special case that is triggered by
specific hit testing flags (active|release). I didn't think it is a good idea to
add a new hit-testing flag for wheel event. Per our discussion offline it maybe
a good idea to move all of that special event specific fallback logic outside
DeprecatedPaintLayer and into EventHandler. +dtapuska who may also be interested
in this.

FF, and IE both behaves by falling back to document but Safari has the same bug
as Chromium.

[Rick Byers, 2015/06/29 17:07:59]

Great!  That code in DeprecatedPaintLayer has seemed sketchy to me for awhile. 
I think this is great evidence that we should be trying to move it out (hoist it
to the EventHandler layer above hit testing).  Then we could at least share the
logic between mouse, touch and wheel events here.  Falling back to dispatching
on the document sounds reasonable to me in all those cases.

If, for some reason, it's too difficult to hoist this special case out, then I'm
also fine with a wheel-specific hack like this.  But maybe add a TODO (here and
in the DeprecatedPaintLayer code) and file a bug to track the cleanup we'd
ultimately like to do.

[majidvp, 2015/06/30 15:33:04]

Created a bug (crbug.com/505825 owned by dtapuska@) to track that work and added
TODO comments referring to it. I think we should land this temporary wheel fix
while we wait for that to be done.

     }
 
+    if (node && !node->dispatchWheelEvent(event))
+        RETURN_WHEEL_EVENT_HANDLED();
+
     // We do another check on the frame view because the event handler can run
     // JS which results in the frame getting destroyed.
     view = m_frame->view();