Changeset 167684 in webkit

Timestamp:

Apr 22, 2014 2:55:59 PM (10 years ago)

Author:

akling@apple.com

Message:

REGRESSION (r151839): Subframe keeps getting mousemove events with the same coordinates after hiding a hovered element.
<​https://webkit.org/b/131974>
<rdar://problem/15907469>

Source/WebCore:
When the currently hovered element disappears as a result of style recalc,
we send a fake mousemove event to the page, to see if anything newly added
should become hovered.

The faking mechanism lives in EventHandler and simply synthesizes a new
mousemove event using the last seen mouse location.

The problem here is that we were sending this fake mousemove event to the
subframe where the hovered element lived. Since subframes aren't kept up
to date on recent mouse locations, this could cause some strange behavior
where a subframe would dispatch mousemove events with stale coordinates.

The solution is to always dispatch fake mousemove events from the main
frame's event handler. This is how real event delivery happens, and hit
testing will then find the appropriate subframe, if any.

Reviewed by Benjamin Poulain.

Test: fast/events/ghostly-mousemoves-in-subframe.html

• dom/Document.cpp:

(WebCore::Document::recalcStyle):

LayoutTests:
Add a test that triggers the weirdness where removing the renderer from
a hovered element in a subframe would leave the subframe's EventHandler
in a state where it could dispatch fake mousemove events with stale
coordinates in response to style recalc.

Note that the final 500ms delay is because fake mousemove events are
sent on 250ms delay timers so we need to give it some time to catch up.

Reviewed by Benjamin Poulain.

• fast/events/ghostly-mousemoves-in-subframe-expected.txt: Added.
• fast/events/ghostly-mousemoves-in-subframe.html: Added.
• platform/mac-wk2/fast/events/resources/ghostly-mousemoves-in-subframe-the-actual-subframe.html: Added.

Location:

trunk

Files:

• LayoutTests/ChangeLog (modified) (1 diff)
• LayoutTests/fast/events/ghostly-mousemoves-in-subframe.html (added)
• LayoutTests/fast/events/resources/ghostly-mousemoves-in-subframe-the-actual-subframe.html (added)
• LayoutTests/platform/mac-wk2/fast/events (added)
• LayoutTests/platform/mac-wk2/fast/events/ghostly-mousemoves-in-subframe-expected.txt (added)
• Source/WebCore/ChangeLog (modified) (1 diff)
• Source/WebCore/dom/Document.cpp (modified) (1 diff)

trunk/LayoutTests/ChangeLog

@@ +1 @@
+2014-04-22  Andreas Kling  <akling@apple.com>
+
+        REGRESSION (r151839): Subframe keeps getting mousemove events with the same coordinates after hiding a hovered element.
+        <https://webkit.org/b/131974>
+        <rdar://problem/15907469>
+
+        Add a test that triggers the weirdness where removing the renderer from
+        a hovered element in a subframe would leave the subframe's EventHandler
+        in a state where it could dispatch fake mousemove events with stale
+        coordinates in response to style recalc.
+
+        Note that the final 500ms delay is because fake mousemove events are
+        sent on 250ms delay timers so we need to give it some time to catch up.
+
+        Reviewed by Benjamin Poulain.
+
+        * fast/events/ghostly-mousemoves-in-subframe-expected.txt: Added.
+        * fast/events/ghostly-mousemoves-in-subframe.html: Added.
+        * platform/mac-wk2/fast/events/resources/ghostly-mousemoves-in-subframe-the-actual-subframe.html: Added.
+
 2014-04-22  Tim Horton  <timothy_horton@apple.com>
 

trunk/Source/WebCore/ChangeLog

@@ +1 @@
+2014-04-22  Andreas Kling  <akling@apple.com>
+
+        REGRESSION (r151839): Subframe keeps getting mousemove events with the same coordinates after hiding a hovered element.
+        <https://webkit.org/b/131974>
+        <rdar://problem/15907469>
+
+        When the currently hovered element disappears as a result of style recalc,
+        we send a fake mousemove event to the page, to see if anything newly added
+        should become hovered.
+
+        The faking mechanism lives in EventHandler and simply synthesizes a new
+        mousemove event using the last seen mouse location.
+
+        The problem here is that we were sending this fake mousemove event to the
+        subframe where the hovered element lived. Since subframes aren't kept up
+        to date on recent mouse locations, this could cause some strange behavior
+        where a subframe would dispatch mousemove events with stale coordinates.
+
+        The solution is to always dispatch fake mousemove events from the main
+        frame's event handler. This is how real event delivery happens, and hit
+        testing will then find the appropriate subframe, if any.
+
+        Reviewed by Benjamin Poulain.
+
+        Test: fast/events/ghostly-mousemoves-in-subframe.html
+
+        * dom/Document.cpp:
+        (WebCore::Document::recalcStyle):
+
 2014-04-22  Myles C. Maxfield  <mmaxfield@apple.com>
 

trunk/Source/WebCore/dom/Document.cpp

@@ -1795 +1795 @@
     // to check if any other elements ended up under the mouse pointer due to re-layout.
     if (m_hoveredElement && !m_hoveredElement->renderer())
-        frameView.frame().eventHandler().dispatchFakeMouseMoveEventSoon();
+        frameView.frame().mainFrame().eventHandler().dispatchFakeMouseMoveEventSoon();
 
     // Style change may reset the focus, e.g. display: none, visibility: hidden.