Fix SitePerProcessTextInputManagerTest.StopTrackingCrashedChildFrame on CFI Bots.

content/browser/frame_host/render_widget_host_view_child_frame.cc

Index: content/browser/frame_host/render_widget_host_view_child_frame.cc
diff --git a/content/browser/frame_host/render_widget_host_view_child_frame.cc b/content/browser/frame_host/render_widget_host_view_child_frame.cc
index 91d0b2ae5c4dda616a28e30621f921a5e67221dd..52644448342d262b3ed7c350fa4139b67c4e549d 100644
--- a/content/browser/frame_host/render_widget_host_view_child_frame.cc
+++ b/content/browser/frame_host/render_widget_host_view_child_frame.cc
@@ -28,6 +28,7 @@
 #include "content/browser/renderer_host/render_widget_host_delegate.h"
 #include "content/browser/renderer_host/render_widget_host_impl.h"
 #include "content/browser/renderer_host/render_widget_host_input_event_router.h"
+#include "content/browser/renderer_host/text_input_manager.h"
 #include "content/common/text_input_state.h"
 #include "content/common/view_messages.h"
 #include "content/public/browser/render_process_host.h"
@@ -287,6 +288,10 @@ void RenderWidgetHostViewChildFrame::Destroy() {
 
   host_->SetView(nullptr);
   host_ = nullptr;
+
+  if (text_input_manager_)
+    text_input_manager_->Unregister(this);

[Charlie Reis, 2016/06/28 18:12:41]

I thought RWHVBase took care of this.  Won't this cause a problem when we get to
~RWHVBase, when text_input_manager_ is still defined but the view is no longer
registered?

If we do actually need this, do all RWHV subclasses need it?

[EhsanK, 2016/06/28 18:56:54]

When we unregister, TextInputManager calls the method
DidUnregisterFromTextInputManager, at which point, the view loses its reference
to TextInputManager:
https://cs.chromium.org/chromium/src/content/browser/renderer_host/text_input...

So I believe we are safe here. But as for why are doing it here, I have to defer
to kenrb@ for better reasons. My justification is that at this point we are done
with the RWHVCF and for what is worth, the observer call for destruction has
already been called on line 287 plus the host is detached from the view. So
there will be no more incoming IPC for TextInputState at this stage.

On the other hand, I do not think the way it was before is wrong. But there will
be a period of time from here until the dtor of base class where we might still
have an active view but no active widget. This will not causes crashes (since we
check against nullptr before using GetActiveWidget()), but is weird.

[kenrb, 2016/06/28 19:34:40]

It isn't necessary, as I understand it, because you added checks in other places
to verify that this view's host is non-NULL. I believe unregistering here is
redundant with those checks because it creates the guarantee that
GetActiveWidget() will return an actual widget.

fwiw, I just filed https://crbug.com/624065 to see about removing the DeleteSoon
call and getting rid of the troublesome state of having living
RenderWidgetHostViews with no RenderWidgetHosts.

+
   base::ThreadTaskRunnerHandle::Get()->DeleteSoon(FROM_HERE, this);
 }