New issue
Advanced search Search tips

Issue 844889 link

Starred by 2 users

Issue metadata

Status: WontFix
Owner: ----
Closed: May 2018
Components:
EstimatedDays: ----
NextAction: ----
OS: Windows
Pri: 2
Type: Bug



Sign in to add a comment

sysexEnabled:false even on https

Reported by ch...@studionexus.ca, May 20 2018

Issue description

UserAgent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/66.0.3359.181 Safari/537.36

Steps to reproduce the problem:
1. run site with https enabled, valid cert.
2. webMidi reporting sysex messages are invalid on port 240

What is the expected behavior?
Following some online advice, I read that sysex messages could be sent if the connection to the site was https. I swiftly went out and purchased an ssl cert, and began digging into it deeper.  

I'm developed an online application for launchpads, a light up / drum pad instrument created by novation / focusrite (www.launchpaddr.com). I'm fairly adept with web midi already and already have a working site which users already use for over a year now. without sysex messages, I can still work within the confines laid out by the manufacturer, with very limited flexibility. 

Without sysex messages, I cannot use full RGB mode, only a limited 128 color palette, so my workaround has been to convert the rgb values into a lookup table which gets referenced on every send. I would really appreciate any advice you could offer getting sysex enabled, as it would greatly improve my user experience. I already have code I've tested in c# / unity working fine, and am working on a webgl Port of it, using webmidi as the backbone. (https://launchpaddr.com/LaunchpaddrPro/) 
if you need to review my js for the connections, it's in https://launchpaddr.com/LaunchpaddrPro/inc/launchpad.js

What went wrong?
Everything works, aside from the sysex messages. 

I think webmidi is groundbreaking for the web and allows for more projects like this to grow. My userbase loves the site, and has sparked others similar to it. 

Did this work before? No 

Does this work in other browsers? Yes

Chrome version: 66.0.3359.181  Channel: stable
OS Version: 10.0
Flash Version: 

I say No - I think it never worked, because I have yet to see an example of sysex over midi. 

I can understand the reasoning behind not wanting to allow sysex messages over http, which is why I was convinced getting a certificate would be my solution. I understand that there is also flashing risks that shouldn't be just attempted at whim obviously, but following the documentation from the manufacturer generally doesn't steer you wrong. 

I'd appreciate any help you could offer. Cheers !
chris@studionexus.ca
 

Comment 1 by phistuck@gmail.com, May 20 2018

On the surface, when querying the API, it seems enabled
> a = navigator.requestMIDIAccess({sysex: true})
Promise {<pending>}
> a
Promise {<resolved>: MIDIAccess}
{__proto__: Promise
[[PromiseStatus]]: "resolved"
[[PromiseValue]]: MIDIAccess
{inputs: MIDIInputMap {size: 0}
onstatechange: null
outputs: MIDIOutputMap {size: 0}
sysexEnabled: true
__proto__: MIDIAccess}
}

(I have not actually tried using it)

Do you get different results from the API itself?
My connection is very similar, however, I call it on window.load:

window.addEventListener('load', function() {        
if (navigator.requestMIDIAccess({sysex:true})) navigator.requestMIDIAccess().then( onMIDIStarted, onMIDISystemError );
});

function onMIDIStarted ( midi ) {
          console.log (midi);
	  midi.onstatechange = midiConnectionStateChange;	 	   	 
	}

midi returns : 

inputs:MIDIInputMap {size: 4}
onstatechange:ƒ midiConnectionStateChange( e )
outputs:MIDIOutputMap {size: 4}
sysexEnabled:false
__proto__:MIDIAccess

Comment 3 by phistuck@gmail.com, May 20 2018

navigator.requestMIDIAccess({sysex:true}) returns a promise (so your if-condition always returns true, for MIDI supporting browsers and an exception for non-supporting browsers) and you end up requesting MIDI access without sysex: true, so I am not sure your code is correct...
I think you need to check whether navigator.requestMIDIAccess exists and if so, call it with sysex: true -
if (navigator.requestMIDIAccess)
{
  navigator.requestMIDIAccess({sysex:true}).then(onMIDIStarted, onMIDISystemError);
}

Comment 4 by phistuck@gmail.com, May 20 2018

Also, I believe Web MIDI in general requires HTTPS (and did so from the beginning), whether you ask for sysex: true or not.
I just ran your code from the console and I do see what you get back from a = navigator.requestMIDIAccess({sysex: true}); 

I was looking for it in the onMidiStarted callback in the midiAccess that gets passed to it. Is this normal ? I would have expected the sysex value to be passed through as well ? 

I will try and change up the code to midi=navigator.requestMIDIAccess({sysex: true}); and ignore the midiAccess that gets passed to onMidiStarted for now. Will keep you posted.

Comment 6 by phistuck@gmail.com, May 20 2018

No, you are correct, only sysex: true requires HTTPS.
http://sites.google.com/a/chromium.org/dev/developers/design-documents/web-midi

Comment 7 by phistuck@gmail.com, May 20 2018

No, midi=navigator.requestMIDI... will not work as you expect, because in this case, midi will be promise, not the WebMIDI object. onMIDIStarted should get the WebMIDI instance as the midi parameter (in your code) and the WebMIDI instance should have a sysexEnabled property.

Comment 8 by phistuck@gmail.com, May 20 2018

*will be a promise

The code and the result I showed in comment 3 is from the console, after expanding the internal [[PromiseValue]] property.
Huzzah! we have liftoff! I've got it up and running in sysex mode with full rgb. Thank you so much for your help! 
20180520_155623.jpg
2.9 MB View Download
Status: WontFix (was: Unconfirmed)
I am glad it worked.

Sign in to add a comment