Interesting.  It seems to me that midi input events should count as a user gesture.

chrisguttandin@ - Thanks for filing the issue...!!

Could you please provide a sample test file/url to test the issue from TE-end.
This will help us in triaging the issue further.

Thanks...!!

I created a little example which is hosted on GitHub: https://chrisguttandin.github.io/web-midi-autoplay-policy-test/.

The source code is available as well: https://github.com/chrisguttandin/web-midi-autoplay-policy-test

Many thanks for looking into this.

Thank you for providing more feedback. Adding the requester to the cc list.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

CC-ing toyoshim@ and cwilso@ to get opinions on this.

I think this issue has some implication of the potential spec work.

Let me confirm.
According to the rtoy's comment at #1, it sounds AudioContext needs a user gesture bit to be resumed by scripts. Right?

MIDI input message may be a kind of a user gesture, but some devices periodically send messages for synchronization, or heart-beating. So, I have a concern that assuming all MIDI inputs as a user gesture introduces an escape hatch.

If we really need this, we would like to allow only chosen messages to have a user gesture bit, for instance only for note-on/off messages. Control-changes are probably also safe, but system messages are not, etc.

But, I'm not sure this is really needed. Even MIDI, we may require another user gesture to use in the future for more secure permission system. If it happens, MIDI message can not be a fast path to resume the AudioContext.

remove Mac bit.

This discussion is platform independent.

Yes, an AudioContext needs a user gesture to resume (or the context must be created from a user gesture).

Can't say if it's really needed, but it does seem to fit in as a user gesture.  And I was only thinking about note-on/off events as counting as a user gesture.

However, I just realized it's quite complicated. ROLI Blocks devices are MIDI devices but the MIDI messages it sends out aren't really MIDI messages.  These use their own protocol with the protocol messages as stream of bits (bytes?) that are then packed into MIDI messages.  It seems possible that some of these could be note-on/off messages that don't actually correspond to actual note on events.

(I didn't examine the protocol in detail, but did look at it briefly many months ago.)

@rtoy/@toyoshim: Could you please let us know whether this issue requires any triaging from TE end. Else feel free to change the status of the bug to untriaged/Available to move this out of TE triaging bucket.

Thanks!

This may be a minor feature proposal that needs a spec discussion rather than a bug. So at this point, this issue does not need helps from TE end.

FYI, Firefox started Web MIDI security discussion at an open thread; https://github.com/mozilla/standards-positions/issues/58

At this point, I feel putting more authority, ability to pass user gesture check, to the API is a little risky.

toyoshim@ Thanks for the update.

As per comment #11, this is a Feature Request.
Hence marking this as Untriaged for further updates from Dev.

Thanks..

Per #11, this is not an implementation bug and we have a tracking issue for the spec. I propose to close this until the spec is fixed.

Can you please point me to the tracking issue for the spec? Many thanks in advance.

chrisguttanding@

Sorry, I was wrong that the issue at #11 was about the user gesture. I think you should file a new issue against Web MIDI API so it can get looked at by the WG.

Just for reference, I created a new issue on GitHub: https://github.com/WebAudio/web-midi-api/issues/186

chrisguttanding@

Thanks for filing the spec issue! : https://github.com/WebAudio/web-midi-api/issues/186