Thanks. We already have it added on the iframe.

toyoshim commented on Dec 16, 2017

Thank you for a quick reply, but was it already rolled out?

I still see warning messages in the console.

Javascript:

navigator.requestMIDIAccess().then(a=>{console.log(a)})

Console:
(index):46 Midi access has been blocked because of a Feature Policy applied to the current document. See https://goo.gl/EuHzyv for more details.
window.onload @ (index):46
(index):1 Uncaught (in promise) DOMException: Midi has been disabled in this document by Feature Policy.

toyoshim commented on Dec 16, 2017

Hum... I quickly looked at index.html, and I can see the "allow" attributes including midi on the iframe for the result. Let me investigate a little...

toyoshim commented on Dec 16, 2017

https://crbug.com/795538 I just filed an issue at chromium crbug.
I'd discuss this with Feature Policy developers there.

Thanks!

toyoshim commented on Dec 20, 2017

Hey, could you explain how you create the result iframe?
When I see the iframe in the Chrome DevTools, it does not have src and srcdoc attributes.

raymes explained how the Feature Policy works here.
https://bugs.chromium.org/p/chromium/issues/detail?id=795538#c6

But, jsfiddle may adopt it in a wrong way.

oskarkrawczyk commented on Dec 20, 2017 •

@toyoshim thanks for the followup.

The way JSFiddle runs a new fiddle (that's not saved) is by using the iframe as a target where a form is submitted to.

Existing fiddles will have the src attribute. I'll have to see if this can be changed.

So as far as I understand the way policy should look is something like this:

<iframe src="//fiddle.jshell.net/..." 
  allow="
    midi;
    geolocation;
    microphone;
    camera //fiddle.jshell.net" 
  sandbox="allow-forms allow-scripts allow-same-origin allow-modals allow-popups" ...></iframe>

<iframe src="//fiddle.jshell.net/..." 
  allow="
    midi //fiddle.jshell.net; 
    geolocation //fiddle.jshell.net; 
    microphone //fiddle.jshell.net; 
    camera //fiddle.jshell.net" 
  sandbox="allow-forms allow-scripts allow-same-origin allow-modals allow-popups" ...></iframe>

I'm not sure about the allow format and couldn't find enough info about it anywhere.

toyoshim commented on Dec 21, 2017 •

Oh I see. I didn't know that the form has such a capability.
If you want to keep the existing way that uses the iframe with a form target, the minimum change should be to add the form action's origin after each feature.

It would be something like this.

<form method="get" action="//fiddle.jshell.net/..." target="result">
  <input type="submit" value="run">
</form>
<iframe
  name="result"
  allow="midi https://fiddle.jshell.net; geolocation https://fiddle.jshell.net; ..."
  sandbox...>
</iframe>

In this iframe, specified features should be available as long as the main document is provided by https://fiddle.jshell.net. You do not need to have unnecessary src attribute here.

One pitfall is that //fiddle.jshell.net won't work as an origin. It should be led by the qualified scheme. If the scheme depends, you need to have both schemes, like "midi http://fiddle.jshell.net https://fiddle.jshell.net; ..."

The allow attribute is in the same format with the Feature-Policy HTTP header line defined in the spec. Casually said

• allow attribute contains policy-directive list separated by ;
• policy-directive contains one feature-name followed by allow-list-value list separated by space
• allow-list-value is one of origin, or special words *, 'self', 'src', or 'none'

toyoshim commented on Dec 21, 2017

If you prefer changing the way to create the result form, and can have src attribute at the frame creation time, the origin of src would be automatically adopted for each feature in allow attribute.

That says, the simplest form <iframe src="//fiddle.jshell.net/..." allow="midi geolocation ..." sandbox...></iframe> should just work.

Thanks!

I notice that encrypted-media is not in the allow list now. Could that be added?

toyoshim commented on Apr 20, 2018

Thank you for fixing the issue, but something is still wrong only in the first run.

1. Open DevTools
2. Access jsfiddle site, and open new editor (given URL was just https://jsfiddle.net/ without any path)
3. Paste 'navigator.requestMIDIAccess().then();' to JavaScript pane
4. Run button => Feature Policy warning and DOMException error will be seen in the DevTools Console
5. Save button to get a unique URL for the code, and reload the page from Chrome
6. Run button => Works without any warning/error

This problem is not critical, but just in case. Maybe the first result pane is created in a different way?

Anyway, now we can use Web MIDI on jsfiddle again. That's wonderful. Thanks!

Hey @oskarkrawczyk

Would you mind fixing the Github embedding iframes as well? this is a repro link.

thanks!

Also thank you for this feature, it so SO nice being able to keep our snippets on GitHub. Love having the version control + great UI for users :)