Initial Implementation of Iframe Attribute for Feature Policy (Part 1)

third_party/WebKit/Source/core/html/HTMLIFrameElement.idl

Index: third_party/WebKit/Source/core/html/HTMLIFrameElement.idl
diff --git a/third_party/WebKit/Source/core/html/HTMLIFrameElement.idl b/third_party/WebKit/Source/core/html/HTMLIFrameElement.idl
index 0a43b108ad1fd5e6c85bb2e2e9a51784fe94be08..c234368d84441521ffc808a2b17bc9d7a77b0c1c 100644
--- a/third_party/WebKit/Source/core/html/HTMLIFrameElement.idl
+++ b/third_party/WebKit/Source/core/html/HTMLIFrameElement.idl
@@ -29,6 +29,10 @@ interface HTMLIFrameElement : HTMLElement {
     [CEReactions, Reflect] attribute boolean allowFullscreen;
     [CEReactions, Reflect] attribute DOMString width;
     [CEReactions, Reflect] attribute DOMString height;
+
+    // Feature Policy allow attribute
+    [CEReactions, PutForwards=value, RuntimeEnabled=FeaturePolicy] readonly attribute DOMTokenList allow;

[iclelland, 2017/02/08 20:11:35]

Should we remove the readonly modifier here? It's not in the spec yet, but I
presume that we'd want to be able to set it at runtime. (And I thought that's
what the JS-path tests were doing, but maybe I'm mistaken there)

[lunalu1, 2017/02/08 21:06:11]

I believe this is what you need to do for DomTokenList. At least all current
DomTokenList's in our codebase are readonly. 

[Rick Byers, 2017/02/09 19:00:35]

You can still add things to a readonly DOMTokenList using the 'add' method.  You
just can't swap it out for a new DOMTokenList.  So yea, I think 'readonly' with
PutForwards is right (that way assigning a string to right hand site will go
through the DOMTokenList value setter).

[lunalu1, 2017/02/09 23:19:04]

Done.

+
     [CheckSecurity=ReturnValue] readonly attribute Document? contentDocument;
     readonly attribute Window? contentWindow;
     [CheckSecurity=ReturnValue, RaisesException] Document? getSVGDocument();