Disallow was_within_same_page = true for a cross-process navigation

content/browser/renderer_host/render_widget_host_impl.cc

Index: content/browser/renderer_host/render_widget_host_impl.cc
diff --git a/content/browser/renderer_host/render_widget_host_impl.cc b/content/browser/renderer_host/render_widget_host_impl.cc
index baf1cc4c75a4ec24ab4afaa3c1617df86882f133..4a21dd4d70f17761ab47cb2a8f2ce561f148b69b 100644
--- a/content/browser/renderer_host/render_widget_host_impl.cc
+++ b/content/browser/renderer_host/render_widget_host_impl.cc
@@ -1469,8 +1469,10 @@ void RenderWidgetHostImpl::Destroy(bool also_delete) {
   if (delegate_)
     delegate_->RenderWidgetDeleted(this);
 
-  if (also_delete)
+  if (also_delete) {
+    CHECK(!owner_delegate_);

[nasko, 2016/03/01 00:27:01]

This looks like unrelated change. If it isn't, let's not put it in this CL.

[gzobqq, 2016/03/01 08:31:42]

It makes sure that a RWHI isn't deleted while owned by a scoped_ptr in RVHI.
This could happen without the additional validation of was_within_same_page in
this CL. So it's not completely unrelated, but not very related either. At first
I thought it would be a good additional check to merge, but now I see that in 48
stable, RVHI still is-a RWHI and RWHI::Destroy is used even with
owner_delegate_. So can't merge it to stable.

I'll create a separate CL for this. I think it's a good CHECK to have. It could
have prevented the UaF since chrome 49, beta. Even with this CL, the RWHI
ownership logic is complicated and there might be more paths leading to this
UaF.

     delete this;
+  }
 }
 
 void RenderWidgetHostImpl::RendererIsUnresponsive() {