Cancelable WebMidi.enable()

[digable1]

Goal: I want to be able to tell WebMidi.enable() to stop waiting and give up.

Why? Automated tests (more e2e-ish that uses real dependencies, not mockups such as for real unit tests).

Specifically:

1. Firefox just started support the WebMidi API - which by definition means WebMIDI.js.
2. I'm using Jasmine with Karma and FirefoxHeadless
3. It gets stuck on WebMidi.enabled() without getting a resolve or reject. I'm suspecting because there's the "are you ok with allowing MIDI" message in this non-secure context in the non-headless mode and headless has not accommodated this new addition to Firefox.

(note: This was not previously a problem because Navigator.requestMIDIAccess was not implemented and noticing the value was 'undefined' meant "don't bother with anything MIDI")

Note: ChromeHeadless "works" - it throws a DOMException, which means at least you're not stuck waiting for the enable() promise to succeed or reject.

Right now I have one of the most hacky workarounds imaginable: I'm doing a setTimeout just before Jasmine is scheduled to timeout, and if we're not through with the setup, I short-circuit the wait by executing the done() function. Yeah, code smell and many other violations!! But I can get through the automation - leaving a dangling Promise in it's wake.

Any thoughts? If there are other better approaches, ignore this one - please!

Thanks!

[djipco]

You might want to check which Firefox version you are using. Up to v107, the Mozilla team has been wanting to use a different security model to implement the Web MIDI API. They finally changed their mind and went with the same model as in Chrome starting with v108 (except for so-called "dangerous capabilities").

Background info on Karim Ratib's blog and on the Mozilla team bug tracker.

[digable1]

This has come up again with a different use case: unit tests.

Do you have a "mock" component when running headless for working with web midi through WebMidiJS? As you might imagine, I can't actually run anything because of the browser security from either FireFox or Chrome (FireFox doesn't even give me an error message, Chrome does give me a security error).

I really don't want to resort to spies, although that is one way to mock the interaction of my calls to WebMidiJS to ensure I don't do something really dumb (assuming I implement the behavior correctly, which is not a confidence builder).

I'm envisioning something like what I think https://www.npmjs.com/package/jazz-midi-headless/v/1.0.3 offers would help here (haven't tried it, so don't know for sure). Assuming it resolved what I'm looking for, I have no idea if something like this package would clash with the WebMidiJS ecosystem (my hunch is it would as there are a few dependencies there). Do you have approaches that would play nicely with unit tests - running headless (for the record, using Jasmine under Karma - yes I want to easily try browsers as opposed to Jest and v8)?

[schoko11]

just a quick thought... you can get around CORS (running in the browser) when starting chrome
with
--allow-file-access-from-files

tried that a few weeks ago on linux mint

[digable1]

This is about MIDI security, not local file access.

Therefore, the error message is (Chrome headless): ERROR [DOMException]: SecurityError - An attempt was made to break through the security policy of the user agent.

Tried this config:

browsers: [ 'ChromeHeadless', 'Chrome_without_security' ],
customLaunchers: {
  Chrome_without_security: {
    base: 'ChromeHeadless',
    flags: ['--disable-web-security', '--disable-site-isolation-trials']
  }
},

Didn't work.

For this use case, even if it worked, I don't want to have a physical device required for unit tests - I'm looking for confidence that I'm using the API correctly in my interactions, not actually playing notes through the device. Hence the "Mock" option.