As part of that work I’ve learned that MIDI access behaves differently in Chrome and Opera (the only two browsers that support Web MIDI to date to my knowledge), and behavior also varies depending on whether HTTP or HTTPS is used to serve your Web MIDI app.
In a nutshell, if you want Web MIDI to work in Opera then you need to serve your page over HTTPS. Web MIDI simply isn’t available in Opera under HTTP. In Chrome, as long as you don’t ask for sysex privileges when requesting MIDI access, you’re good with HTTP; if you need sysex then you’re going to need to serve your page over HTTPS.
The following table summarizes the behavior of different scenarios across both browsers.
|HTTP w/o Sysex||HTTP with Sysex||HTTPS w/o Sysex||HTTPS w/o Sysx|
|Chrome||Granted, no prompt||Denied, no prompt||Granted, no prompt||Prompt user|
|Opera||Denied, no prompt||Denied, no prompt||Prompt user||Prompt user|
Here’s what the Web MIDI spec has to say about requesting MIDI access:
Requesting MIDI access should prompt the user for access to MIDI devices, particularly if system exclusive access is requested. In some scenarios, this permission may have already been implicitly or explicitly granted, in which case this prompt may not appear. If the user gives express permission or the call is otherwise approved, the vended Promise is resolved. The underlying system may choose to allow the user to select specific MIDI interfaces to expose to this API (i.e. pick and choose interfaces on an individual basis), although this is not required. The system may also choose to prompt (or not) based on whether system exclusive support is requested, as system exclusive has greater privacy and security implications.
If the user declines or the call is denied for any other reason, the Promise is rejected with a DOMException parameter.
This doesn’t give any guidance about HTTP vs HTTPS though step 3 of the midi access algorithm outlined in the spec states, “Optionally, e.g. based on a previously-established user preference, for security reasons, or due to platform limitations, jump to the step labeled failure below.” Presumably Opera rejects MIDI access over HTTP for security reasons though it would be nice if it matched Chrome’s behavior and allowed MIDI access over HTTP provided the page doesn’t ask for sysex. Maybe they’ll change that.
To demonstrate the behaviors outlined in the table, I’ve put together a couple of CodePens that ask for MIDI access with and without sysex. Fortunately you can access CodePen via HTTP or HTTPS so it serves as a good test bed for the combinations we need. You can try them out yourself.
- HTTP with Sysex: http://codepen.io/bschmaus/pen/bqrMOV
- HTTP w/o Sysex: http://codepen.io/bschmaus/pen/WpEJYw
- HTTPS with Sysex: https://codepen.io/bschmaus/pen/bqrMOV
- HTTPS w/o Sysex: https://codepen.io/bschmaus/pen/WpEJYw
Here’s what you’ll see in the CodePens when access is denied:
Here’s what the CodePen output looks like when access is granted:
Chrome’s prompt (you’ll see it if you ask for sysex over HTTPS) looks like this:
And here’s what Opera’s prompt looks like (you’ll see it regardless of sysex over HTTPS; access blocked over HTTP):
If you get different behavior than outlined in the table in the CodePens then pull up your browser settings and type “midi” into the search box. Then click the “Manage Exceptions” button where you’ll see a dialog like follows. If you’ve previously allowed/blocked access for CodePen then you’ll need to remove the record in the dialog (mouseover and click the “x”) and re-run the CodePen.
So…if you’re developing a Web MIDI app and want to support both Chrome and Opera then you need to use HTTPS. For apps that don’t need sysex, as long as you’re good with limiting yourself to Chrome, then you’re fine serving your app up via HTTP.
Let me know if your experience has been different than mine, and Opera devs, it’d be great if you could update your Web MIDI implementation to allow MIDI access over HTTP without sysex.