Replicate feature policy headers to remote frames

content/renderer/render_frame_impl.cc

 // Copyright 2013 The Chromium Authors. All rights reserved.
 // Use of this source code is governed by a BSD-style license that can be
 // found in the LICENSE file.
 
 #include "content/renderer/render_frame_impl.h"
 
 #include <map>
 #include <string>
 #include <utility>
 #include <vector>
@@ skipping 3104 matching lines @@
   Send(new FrameHostMsg_UpdateToUniqueOrigin(
       routing_id_, is_potentially_trustworthy_unique_origin));
 }
 
 void RenderFrameImpl::didChangeSandboxFlags(blink::WebFrame* child_frame,
                                             blink::WebSandboxFlags flags) {
   Send(new FrameHostMsg_DidChangeSandboxFlags(
       routing_id_, GetRoutingIdForFrameOrProxy(child_frame), flags));
 }
 
+void RenderFrameImpl::didSetFeaturePolicyHeader(
+    const blink::WebString& header_value) {
+  if (!SiteIsolationPolicy::AreCrossProcessFramesPossible())
+    return;

[raymes, 2016/11/07 23:10:25]

Hmm - we will want this to be replicated to the browser even if site isolation
is disabled. Do you know if that will still happen with this check in place?
Should we remove it? alexmos@ might know.

[iclelland, 2016/11/08 03:13:41]

That's a good point - once we start using it for browser-side features /
permissions, then we will want to send this to the browser. I can remove it
here, or we can remove it later, once it's used for something other than site
isolation.

[alexmos, 2016/11/09 01:16:55]

I'd say just remove this now.  

AreCrossProcessFramesPossible would be true if any kind of OOPIF mode is active,
and it's already true for lots of canary/dev/beta users in our field trial for
--isolate-extensions.  The value of this on ToT had been true for a while; we
had to flip it to false recently but anticipate turning it back on after branch
point.

I think it's ok to just always send the IPC, as down the road, if your
browser-side code starts relying on the header and you forget to remove this,
you might have a nasty surprise if ToT value of this is |true|, but our field
trials make it |false| for some users.

On that note, if you plan to use this on the browser side, it'd be good to have
a browsertest to verify the feature_policy_header on FrameTreeNode (see the CSP
and other replication tests in SitePerProcessBrowserTest).  Probably fine if you
want to add it later though, given that you have end-to-end coverage with your
layout test.

[iclelland, 2016/11/09 18:07:59]

Done, make sense. Thanks.
Added https://bugs.chromium.org/p/chromium/issues/detail?id=663731 so it doesn't
get forgotten.

+  Send(new FrameHostMsg_DidSetFeaturePolicyHeader(
+      routing_id_, base::UTF16ToUTF8(base::StringPiece16(header_value))));
+}
+
 void RenderFrameImpl::didAddContentSecurityPolicy(
     const blink::WebString& header_value,
     blink::WebContentSecurityPolicyType type,
     blink::WebContentSecurityPolicySource source) {
   if (!SiteIsolationPolicy::AreCrossProcessFramesPossible())
     return;
 
   ContentSecurityPolicyHeader header;
   header.header_value = base::UTF16ToUTF8(base::StringPiece16(header_value));
   header.type = type;
@@ skipping 3439 matching lines @@
   // event target. Potentially a Pepper plugin will receive the event.
   // In order to tell whether a plugin gets the last mouse event and which it
   // is, we set |pepper_last_mouse_event_target_| to null here. If a plugin gets
   // the event, it will notify us via DidReceiveMouseEvent() and set itself as
   // |pepper_last_mouse_event_target_|.
   pepper_last_mouse_event_target_ = nullptr;
 #endif
 }
 
 }  // namespace content