[MPArch] Avoid InterceptorThrottle for prerender

This CL makes it so that the InterceptNavigationThrottle is created only
for *primary* main frame navigations. This means it will not be created
when navigating a main frame in a prerender (for example).

The effect of this is that prerendering a URL that would normally be
intercepted and opened by an Android Intent will now be loaded by the
browser without being intercepted. This prevents a prerendering page,
which the user hasn't consciously navigated to, from unexpectedly
launching an intent.

However, since we don't run navigation throttles when activating the
prerender, activating the prerendered page will show in the browser,
which may be unexpected (e.g. the user expects YouTube links to open in
the YouTube app). This would require the InterceptNavigationThrottle to
cancel prerendering in cases where it would intercept the navigation
without launching the intent.  However, this is difficult to do because
the throttle logic is complicated and the decision of whether or not to
intercept is tightly coupled with launching the intent. The throttle
would have to be significantly refactored to make this work so for now
we opt for the non-ideal but non-broken behavior.

For more detail, see comments in the conversion guide doc:
https://docs.google.com/document/d/1NWslHvbFPcBKVEn5dwc0TEzbSnJh63OWW0miWSnG6Qo/edit?disco=AAAAMVD9TaM

Change-Id: I2b318d23020f107e2126151154684030c244495c
Bug: 1199724,1227659
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2823808
Commit-Queue: David Bokan <[email protected]>
Reviewed-by: Nate Fischer <[email protected]>
Reviewed-by: Matt Falkenhagen <[email protected]>
Reviewed-by: Clark DuVall <[email protected]>
Reviewed-by: Andrew Grieve <[email protected]>
Cr-Commit-Position: refs/heads/master@{#899984}
diff --git a/components/navigation_interception/intercept_navigation_delegate.cc b/components/navigation_interception/intercept_navigation_delegate.cc
index bd55764..a4e4d29 100644
--- a/components/navigation_interception/intercept_navigation_delegate.cc
+++ b/components/navigation_interception/intercept_navigation_delegate.cc
@@ -13,6 +13,7 @@
 #include "components/navigation_interception/jni_headers/InterceptNavigationDelegate_jni.h"
 #include "components/navigation_interception/navigation_params_android.h"
 #include "content/public/browser/browser_thread.h"
+#include "content/public/browser/navigation_handle.h"
 #include "content/public/browser/navigation_throttle.h"
 #include "content/public/browser/render_frame_host.h"
 #include "content/public/browser/render_view_host.h"
@@ -68,9 +69,24 @@
 
 // static
 std::unique_ptr<content::NavigationThrottle>
-InterceptNavigationDelegate::CreateThrottleFor(
+InterceptNavigationDelegate::MaybeCreateThrottleFor(
     content::NavigationHandle* handle,
     navigation_interception::SynchronyMode mode) {
+  // Navigations in a subframe or non-primary frame tree should not be
+  // intercepted. As examples of a non-primary frame tree, a navigation
+  // occurring in a Portal element or an unactivated prerendering page should
+  // not launch an app.
+  // TODO(bokan): This is a bit of a stopgap approach since we won't run
+  // throttles again when the prerender is activated which means links that are
+  // prerendered will avoid launching an app intent that a regular navigation
+  // would have. Longer term we'll want prerender activation to check for app
+  // intents, or have this throttle cancel the prerender if an intent would
+  // have been launched (without launching the intent). It's also not clear
+  // what the right behavior for <portal> elements is.
+  // https://crbug.com/1227659.
+  if (!handle->IsInPrimaryMainFrame())
+    return nullptr;
+
   return std::make_unique<InterceptNavigationThrottle>(
       handle, base::BindRepeating(&CheckIfShouldIgnoreNavigationOnUIThread),
       mode);