Note: other features are also disallowed regardless of the allow attribute existence.

I'm not sure if this is the case for the jsfiddle, but I found one inconsistent behavior on the policy adoption.

Test1.html:
<iframe allow="midi" srcdoc="<script>location.href='http://cross-origin/midi.html'"</iframe>

Test2.html:
<iframe allow="midi" src="http://cross-origin/nav_to_midi.html"></ioframe>

nav_to_miid.html:
<script>location.href='midi.html'</script>

midi.html:
<script>navigation.requestMIDIAccess().then(a=>console.log(a));

In this example, Test1.html does not allow to use MIDI in midi.html, but Test2.html allows.

Raymes, is this an expected behavior?

Oops, some typos in my example. Here is a fixed one just in case.

Test1.html:
<iframe allow="midi" srcdoc="<script>location.href='http://cross-origin/midi.html'"</iframe>

Test2.html:
<iframe allow="midi" src="http://cross-origin/nav_to_midi.html"></iframe>

nav_to_midi.html:
<script>location.href='midi.html'</script>

midi.html:
<script>navigation.requestMIDIAccess().then(a=>console.log(a));

Hey toyoshim: the issue here is that we use the "src" attribute of the iframe to determine what the policy should be. If you just say allow="midi" it will apply only to the document specified in src. This is an explicit decision because otherwise websites may be loaded into the frame that developers don't want/expect to be granted permission.

If you want other sites in the frame to be granted access, you can specify an allowlist using the same syntax as the header, e.g.:
allow="microphone https://example.com"

If a "sandbox" attribute is specified, it will make the origin of the embedded document unique. In that case, I believe that currently the only way to properly delegate the feature is to delegate to all embedded origins using allow="midi *". That actually really isn't ideal at all though since it means that the frame can be navigated to another origin and access can be inherited. But this may be a short-term workaround.

iclelland/lunalu: A few questions here:

1) If "sandbox" or "srcdoc" is specified, is it true that a * policy is currently needed to delegate the feature? Can we do better than that? (I think Ian may have been looking into this)

2) The question of exactly how allow="midi" works (in that it defaults to the src of the iframe) has come up a few times. It could be good to add an example in the explainer that we can point people to? 

(btw I've reduced to P2 based on the fact that I think there is a workaround for srcdoc and sanbox. But if that turns out not to be the case let's bump it back up to P1)

Thank you for clarification.

When I looked at their jsfiddle site, the iframe does not have have both src and srcdoc in the DevTool, but actually it shows a cross-origin content inside it. I have no idea how they create this frame. I'd ask them.

I can get a similar iframe instance by the following step.

1. insert an iframe with srcdoc contains script tag that navigates to a cross-origin content
2. clear srcdoc attribute
3. now iframe does not have src and srcdoc, but contains a cross-origin content

So, probably adding origins to the allowlist in the step 1 would work.

For escaping from the sandbox, what happens in my scenario above? Does the iframe still keep the unique origin with the sandbox restrictions even after a navigation?

Sorry for many questions. I may need to read the spec.

Hey toyoshim: I'm not sure exactly about all the behaviors of sandbox and srcdoc.

But my understanding is that navigating inside an <iframe sandbox> will not "escape" the sandbox and the site should continue to have a unique origin and have sandbox restrictions apply to it.

If sandbox was not present, I would expect adding origins to the allowlist to work assuming that the document inside the frame had a well-defined origin (regardless of whether the content was first initialized using srcdoc or some other method).

However the above are just my expectations and I haven't fully tested these scenarios. Regardless, I expect that using a * allowlist would delegate permission in all of the above scenarios.

Thank you raymes,

jsfiddle's case was different, actually.
They used form target to put the iframe content, like

 <form method="get" action="//cross-origin.net/..." target="result"><input type="submit" value="ruin"></form>
 <iframe name="result" allow="midi ..." sandbox...></iframe>

I didn't know that form can do such magical thing, but I finally understood what happened here.

So, in their case, what they need is to put predefined origins in the feature directives in the allow attribute.

The specific problem in the jsfiddle would be solved with this right Feature Policy adoption.

Let me just rename the issue subject.
Probably, what we still need to do in this bug is to clarify the behavior when we use "allow" attribute with "sandbox" or "srcdoc", as raymes asked at comment 6.