Fix process transfers for blob urls of sites requiring dedicated processes.

content/browser/frame_host/render_frame_host_manager.cc

Index: content/browser/frame_host/render_frame_host_manager.cc
diff --git a/content/browser/frame_host/render_frame_host_manager.cc b/content/browser/frame_host/render_frame_host_manager.cc
index 571bf33c2943f76939b8a24702f24bcb557ebb28..49a72baaa216a9feccf7054038ac2175cf73b7b5 100644
--- a/content/browser/frame_host/render_frame_host_manager.cc
+++ b/content/browser/frame_host/render_frame_host_manager.cc
@@ -1446,7 +1446,7 @@ bool RenderFrameHostManager::IsRendererTransferNeededForNavigation(
   }
 
   BrowserContext* context = rfh->GetSiteInstance()->GetBrowserContext();
-  GURL effective_url = SiteInstanceImpl::GetEffectiveURL(context, dest_url);
+  GURL site_url = SiteInstanceImpl::GetSiteForURL(context, dest_url);
 
   // TODO(nasko, nick): These following --site-per-process checks are
   // overly simplistic. Update them to match all the cases
@@ -1460,8 +1460,7 @@ bool RenderFrameHostManager::IsRendererTransferNeededForNavigation(
   // The sites differ. If either one requires a dedicated process,
   // then a transfer is needed.
   if (rfh->GetSiteInstance()->RequiresDedicatedProcess() ||
-      SiteInstanceImpl::DoesSiteRequireDedicatedProcess(context,
-                                                        effective_url)) {
+      SiteInstanceImpl::DoesSiteRequireDedicatedProcess(context, site_url)) {

[Charlie Reis, 2016/09/09 18:54:39]

Can you explain why was passing the effective URL wrong?

I noticed that DoesSiteRequireDedicatedProcess is documented to expect an
effective_url (in site_instance_impl.h).  Same for
ContentBrowserClient::DoesSiteRequireDedicatedProcess.  Should we change that
documentation?  The parameter names are also inconsistent: it's effective_url
until we get to chrome_content_browser_client.cc, when it becomes
effective_site_url.

There are two other callsites: SII::RequiresDedicatedProcess (which passes a
site URL) and RFHM::DetermineSiteInstanceForURL (which apparently passes a
normal URL, neither effective nor site, in TDI mode).  Is the latter one a
problem?

     return true;
   }