PlzNavigate: make MHTML iframe load working.

content/common/navigation_params.cc

 // Copyright 2014 The Chromium Authors. All rights reserved.
 // Use of this source code is governed by a BSD-style license that can be
 // found in the LICENSE file.
 
 #include "content/common/navigation_params.h"
 
 #include "base/logging.h"
 #include "build/build_config.h"
 #include "content/common/service_worker/service_worker_types.h"
 #include "content/public/common/appcache_info.h"
 #include "content/public/common/browser_side_navigation_policy.h"
 #include "content/public/common/url_constants.h"
 #include "url/gurl.h"
 #include "url/url_constants.h"
 #include "url/url_util.h"
 
 namespace content {
 
 // PlzNavigate
 bool ShouldMakeNetworkRequestForURL(const GURL& url) {
   CHECK(IsBrowserSideNavigationEnabled());
 
   // Javascript URLs, srcdoc, schemes that don't load data should not send a
   // request to the network stack.
   if (url.SchemeIs(url::kJavaScriptScheme) || url.is_empty() ||
-      url.SchemeIs(url::kContentIDScheme) || url == content::kAboutSrcDocURL) {

[nasko, 2017/05/03 17:28:39]

The comments in this CL say that "cid:" cannot be encountered outside of MTHML.
Those don't go to the network stack, so why are we changing this method to
return true for it?

[arthursonzogni, 2017/05/04 14:26:32]

You are right, the "cid:" cannot be encountered outside of a MHTML Archive.
Without PlzNavigate, when there is no MHTML Archive, the request will continue
inside the ResourceFetcher and the renderer will ask the browser for the
resource. Doing this modification in ShouldMakeNetworkRequestForURL leads to
have the same behavior with PlzNavigate. E.G. using the browser to open the
"cid:" url.
The user will be asked which application he/she want to use to open the "cid:"
URL.

Alternatively, we can make it always use the ResourceFetcher and I can add a
line of code that make the request to be ignored if there is no archives and the
url protocol is "cid:"
I will do it in the next patch. Please tell what do you prefer.

[nasko, 2017/05/04 15:48:18]

Would the cid: scheme have a valid URL as the rest of the string? If not, then
there is no reason to send it up to the browser, as it will not be able to open
it correctly.
Isn't this logically handled by LoadURLExternally?
The answer will depend on whether cid:<...> can have a valid URL as <...>, which
I don't know of the top of my head.

[arthursonzogni, 2017/05/05 09:07:46]

It will not have a valid URL as the rest of the string. After cid: there is a
uniquely identified string that should match the content of the "Content-ID"
header of a resource in the MHTML Archive.
I don't think so. I have checked.
AFAIK, I don't think.

+      url == content::kAboutSrcDocURL) {
     return false;
   }
 
   for (const auto& scheme : url::GetEmptyDocumentSchemes()) {
     if (url.SchemeIs(scheme))
       return false;
   }
 
   return true;
 }
@@ skipping 184 matching lines @@
     const RequestNavigationParams& request_params)
     : common_params(common_params),
       start_params(start_params),
       request_params(request_params) {
 }
 
 NavigationParams::~NavigationParams() {
 }
 
 }  // namespace content