Introduce AncestorThrottle, which will process 'X-Frame-Options' headers.

content/browser/loader/navigation_resource_throttle.cc

Index: content/browser/loader/navigation_resource_throttle.cc
diff --git a/content/browser/loader/navigation_resource_throttle.cc b/content/browser/loader/navigation_resource_throttle.cc
index 9112f7e8d8919dba6030a0eeae48843563e48c21..81952ba9a58da18b941d10acfbfc8310a3878b6c 100644
--- a/content/browser/loader/navigation_resource_throttle.cc
+++ b/content/browser/loader/navigation_resource_throttle.cc
@@ -235,6 +235,8 @@ void NavigationResourceThrottle::OnUIChecksPerformed(
     controller()->CancelAndIgnore();
   } else if (result == NavigationThrottle::CANCEL) {
     controller()->Cancel();
+  } else if (result == NavigationThrottle::BLOCK_RESPONSE) {
+    controller()->CancelWithError(net::ERR_BLOCKED_BY_RESPONSE);

[mmenke, 2016/05/02 18:17:29]

Is this only for subframes, or is it for the main frame, too?  Note that when we
fail with any error except for ERR_ABORTED, we commit the error page.

For main frames only, if the page was not generated by a POST, we try to
automatically reload the page, which I assume will lose whatever context this
caused us to error out the page.  For POSTs, F5 will show a re-post confirmation
dialog and then allow users to actually load the page.  Even without
auto-reload, the user can reload a page manually, and session restore will do
the same. 

[Mike West, 2016/05/05 08:14:28]

The throttle introduced in this CL is only for subframes. In theory, throttles
could be added which would cancel the main frame as well. I'll add a comment
here noting the special considerations for main frame cancellations; if we add
that kind of functionality, we'll need to carefully consider what the right
behavior ought to be.

   } else {
     controller()->Resume();
   }