Abort forwarding remote input events when layoutObject is gone.

It is possible for an input event that will be forwarded to a remote
frame to also cause the iframe element in the local renderer to become
hidden, which destroys the layoutObject for that element. This was
causing a crash because the forwarding code requires a layoutObject for
mouse event conversion.

This patch causes event forwarding to abort in that situation.

No test because we don't yet have layout tests running with
--site-per-process.

BUG=520705
R=dcheng@chromium.org

Review URL: https://codereview.chromium.org/1298973002

git-svn-id: svn://svn.chromium.org/blink/trunk@200904 bbb929c8-8fbe-4397-9dbb-9b2b20218538

third_party/WebKit/Source/web/RemoteFrameClientImpl.cpp

@@ -126,6 +126,19 @@ unsigned RemoteFrameClientImpl::backForwardLength()
 // process. See http://crbug.com/339659.
 void RemoteFrameClientImpl::forwardInputEvent(Event* event)
 {
+    // It is possible for a platform event to cause the remote iframe element
+    // to be hidden, which destroys the layout object (for instance, a mouse
+    // event that moves between elements will trigger a mouseout on the old
+    // element, which might hide the new element). In that case we do not
+    // forward. This is divergent behavior from local frames, where the
+    // content of the frame can receive events even after the frame is hidden.
+    // We might need to revisit this after browser hit testing is fully
+    // implemented, since this code path will need to be removed or refactored
+    // anyway.
+    // See https://crbug.com/520705.
+    if (!toCoreFrame(m_webFrame)->ownerLayoutObject())
+        return;
+
     // This is only called when we have out-of-process iframes, which
     // need to forward input events across processes.
     // FIXME: Add a check for out-of-process iframes enabled.