PlzNavigate: make MHTML iframe load working.

content/common/navigation_params.cc

Index: content/common/navigation_params.cc
diff --git a/content/common/navigation_params.cc b/content/common/navigation_params.cc
index e2148964f89b3e177019e997c16d72147d7d2a82..28b286c2592479319f9e634fd941ff6adc73a6a8 100644
--- a/content/common/navigation_params.cc
+++ b/content/common/navigation_params.cc
@@ -23,7 +23,7 @@ bool ShouldMakeNetworkRequestForURL(const GURL& url) {
   // 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;
   }