Move compositor InputHandler from RenderViewImpl to RenderWidget.

third_party/WebKit/Source/core/loader/FrameLoader.cpp

 /*
  * Copyright (C) 2006, 2007, 2008, 2009, 2010, 2011 Apple Inc. All rights
  * reserved.
  * Copyright (C) 2008 Nokia Corporation and/or its subsidiary(-ies)
  * Copyright (C) 2008, 2009 Torch Mobile Inc. All rights reserved.
  * (http://www.torchmobile.com/)
  * Copyright (C) 2008 Alp Toker <alp@atoker.com>
  * Copyright (C) Research In Motion Limited 2009. All rights reserved.
  * Copyright (C) 2011 Kris Jordan <krisjordan@gmail.com>
  * Copyright (C) 2011 Google Inc. All rights reserved.
@@ skipping 1305 matching lines @@
     RefPtr<SecurityOrigin> securityOrigin =
         SecurityOrigin::create(m_provisionalDocumentLoader->request().url());
     m_provisionalDocumentLoader->timing().setHasSameOriginAsPreviousDocument(
         securityOrigin->canRequest(m_frame->document()->url()));
   }
 
   if (!prepareForCommit())
     return;
 
   if (isLoadingMainFrame()) {
+    // TODO(wjmaclean): Instead of passing |m_frame| here we pass nullptr
+    // instead so the properties will be set on the WebView. We do this since,
+    // while we are loading, the WebFrameWidget for m_frame may not yet
+    // be available.

[dcheng, 2016/11/04 21:00:02]

Can we switch the order of initialization in CreateMainFrame so this case can't
happen?

[wjmaclean, 2016/11/07 15:57:27]

It's possible we can switch the order, though I don't know for sure yet. If we
*do* switch the order, might it be safe to try that in a follow-on CL, one that
is a bit smaller and easier to reason about?

[dcheng, 2016/11/08 18:11:00]

Can we investigate doing this cleanup preemptively? We've been trying to
rationalize when things can be null in Blink: as you've experienced, it's far
too arbitrary at the moment. =)

[wjmaclean, 2016/11/09 18:09:38]

Actually, as I recall, this only seems to have been an issue in unit tests. I
checked this out further, and in those tests, the frameWidget is *never* created
it seems, so it's not something we need to change (other than handling the null
pointer case). I added a check in ChromeClientImpl that includes a LOG message
(I'm open to more useful wording for that message if you have any suggestions).

     m_frame->page()->chromeClient().setEventListenerProperties(
-        WebEventListenerClass::TouchStartOrMove,
+        nullptr, WebEventListenerClass::TouchStartOrMove,
         WebEventListenerProperties::Nothing);
     m_frame->page()->chromeClient().setEventListenerProperties(
-        WebEventListenerClass::MouseWheel, WebEventListenerProperties::Nothing);
+        nullptr, WebEventListenerClass::MouseWheel,
+        WebEventListenerProperties::Nothing);
     m_frame->page()->chromeClient().setEventListenerProperties(
-        WebEventListenerClass::TouchEndOrCancel,
+        nullptr, WebEventListenerClass::TouchEndOrCancel,
         WebEventListenerProperties::Nothing);
   }
 
   client()->transitionToCommittedForNewPage();
   m_frame->navigationScheduler().cancel();
   m_frame->editor().clearLastEditCommand();
 
   // If we are still in the process of initializing an empty document then its
   // frame is not in a consistent state for rendering, so avoid
   // setJSStatusBarText since it may cause clients to attempt to render the
@@ skipping 602 matching lines @@
                          m_documentLoader ? m_documentLoader->url() : String());
   return tracedValue;
 }
 
 inline void FrameLoader::takeObjectSnapshot() const {
   TRACE_EVENT_OBJECT_SNAPSHOT_WITH_ID("loading", "FrameLoader", this,
                                       toTracedValue());
 }
 
 }  // namespace blink