Introduce content-side Feature Policy object and maintain in parallel with renderer policy.

content/browser/frame_host/render_frame_host_impl.h

Index: content/browser/frame_host/render_frame_host_impl.h
diff --git a/content/browser/frame_host/render_frame_host_impl.h b/content/browser/frame_host/render_frame_host_impl.h
index e904d8fe4bc609dd2664c1a1d572e1cd9f439a23..9b6fbc1e208013b2982963bfdfacf09eba0f3748 100644
--- a/content/browser/frame_host/render_frame_host_impl.h
+++ b/content/browser/frame_host/render_frame_host_impl.h
@@ -80,6 +80,7 @@ namespace content {
 class AppWebMessagePortMessageFilter;
 class AssociatedInterfaceProviderImpl;
 class CrossProcessFrameConnector;
+class FeaturePolicy;
 class FrameTree;
 class FrameTreeNode;
 class MediaInterfaceProxy;
@@ -589,6 +590,13 @@ class CONTENT_EXPORT RenderFrameHostImpl
   // in a non-loading state.
   void ResetLoadingState();
 
+  // Returns the feature policy which should be enforced on this RenderFrame.
+  const FeaturePolicy* GetFeaturePolicy();

[alexmos, 2017/02/09 05:59:50]

nit: no const (see a note in
https://www.chromium.org/developers/content-module/content-api about this)

[iclelland, 2017/02/09 17:16:18]

Done. (I thought this only applied to headers in content/public, ie.
render_frame_host.h, but I'm fine with this here as well. Returning a nonconst
object allows callers to modify the policy, but I don't have any reason to think
that people would accidentally do that.)

+
+  // Clears any existing policy and constructs a new policy for this frame,
+  // based on its parent frame.
+  void ResetFeaturePolicy();
+
   // Tells the renderer that this RenderFrame will soon be swapped out, and thus
   // not to create any new modal dialogs until it happens.  This must be done
   // separately so that the ScopedPageLoadDeferrers of any current dialogs are
@@ -1143,6 +1151,9 @@ class CONTENT_EXPORT RenderFrameHostImpl
   // See BindingsPolicy for details.
   int enabled_bindings_ = 0;
 
+  // Tracks the feature policy which has been set on this frame.
+  std::unique_ptr<FeaturePolicy> feature_policy_;

[alexmos, 2017/02/09 05:59:50]

Currently, seems like this will be null from the time the frame is created until
its first navigation commits.  I see that this is the current behavior in Blink
also, so just curious about why we wouldn't want to initialize the feature
policy to something at frame creation time so it's always non-null (so callers
don't have to potentially null-check GetFeaturePolicy()).  I guess we won't know
the origin until the commit, though on the other hand, I think Blink considers a
new subframe's initial blank document to be in its parent's origin before
commit.

[iclelland, 2017/02/09 17:16:17]

Acknowledged. I'll see about doing an explicit pre-navigation-commit init of the
policy in a future CL; it will clear up any other call sites.

+
   // NOTE: This must be the last member.
   base::WeakPtrFactory<RenderFrameHostImpl> weak_ptr_factory_;