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

Source/core/input/EventHandler.cpp

 /*
  * Copyright (C) 2006, 2007, 2008, 2009, 2010, 2011 Apple Inc. All rights reserved.
  * Copyright (C) 2006 Alexey Proskuryakov (ap@webkit.org)
  * Copyright (C) 2012 Digia Plc. and/or its subsidiary(-ies)
  *
  * Redistribution and use in source and binary forms, with or without
  * modification, are permitted provided that the following conditions
  * are met:
  * 1. Redistributions of source code must retain the above copyright
  *    notice, this list of conditions and the following disclaimer.
@@ skipping 1744 matching lines @@
 
     if (node) {
         // Figure out which view to send the event to.
         LayoutObject* target = node->layoutObject();
 
         if (isOverWidget && target && target->isLayoutPart()) {
             Widget* widget = toLayoutPart(target)->widget();
             if (widget && passWheelEventToWidget(event, *widget))
                 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();
-    }
+    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();
     if (!view)
         return false;
 
     if (view->scrollableArea()->handleWheel(event).didScroll())
         RETURN_WHEEL_EVENT_HANDLED();
 
@@ skipping 1982 matching lines @@
 unsigned EventHandler::accessKeyModifiers()
 {
 #if OS(MACOSX)
     return PlatformEvent::CtrlKey | PlatformEvent::AltKey;
 #else
     return PlatformEvent::AltKey;
 #endif
 }
 
 } // namespace blink