Replicate a parsed feature policy representation so it doesn't need to be parsed in the browser pro…

content/browser/frame_host/render_frame_host_impl.cc

Index: content/browser/frame_host/render_frame_host_impl.cc
diff --git a/content/browser/frame_host/render_frame_host_impl.cc b/content/browser/frame_host/render_frame_host_impl.cc
index 8025c71da8d2e87e350907864428a552ff12c2fd..456ac049b85c1ca122dd6d88c5e441c0cbb7419d 100644
--- a/content/browser/frame_host/render_frame_host_impl.cc
+++ b/content/browser/frame_host/render_frame_host_impl.cc
@@ -1769,8 +1769,8 @@ void RenderFrameHostImpl::OnDidChangeName(const std::string& name,
 }
 
 void RenderFrameHostImpl::OnDidSetFeaturePolicyHeader(
-    const std::string& header) {
-  frame_tree_node()->SetFeaturePolicyHeader(header);
+    const std::vector<FeaturePolicyParsedWhitelist>& parsed_header) {

[alexmos, 2016/12/01 02:04:19]

nit: I'm curious if we could make the type a bit more readable.  Is "Parsed"
needed in the whitelist class name, or would it be simpler to name it
FeaturePolicyWhitelist, or even just FeatureWhitelist to emphasize that it's a
per-feature whitelist and not per-policy?

Alternatively, maybe you could repeat what you did with WebParsedFeaturePolicy
and define the whole parsed header type as ParsedFeaturePolicy?

[raymes, 2016/12/01 03:03:09]

In blink I was trying to distinguish it from the FeaturePolicy::Whitelist class.
We don't have anything like that in content/ yet but we may have something as we
try to share logic between browser/renderer. So I think it's safer to keep the
FaturePolicyParsedWhitelist name. I can definitely do the typdef you suggest
though.

[alexmos, 2016/12/01 22:27:54]

Acknowledged.

+  frame_tree_node()->SetFeaturePolicyHeader(parsed_header);
 }
 
 void RenderFrameHostImpl::OnDidAddContentSecurityPolicy(