Open padenot opened 2 years ago
I'm not sure which way is best but I agree that it should be clarified in the spec since developer expectations will most likely diverge on this topic.
Generally-speaking, is there an advantage for Gecko to do it asynchronously? Does this advantage outweigh the fact that it introduces an incompatibility between implementations?
I don't think there is, it waiting isn't in the spec, so we didn't implement it, the Promise
is tied to the permission acceptation in our implementation, not the enumeration.
This part of the spec is a bit hand wavy, there's no explicit enumeration steps, and thus it's unclear when to resolve the promise. This can be changed, and we can fix our implementation to resolve slightly later.
Per you last comment, it is now clear that the spec should be updated to clarify the sequence. I suggest we align the spec with Chromium's existing behaviour so we do not introduce an unnecessary incompatibility.
That would seem best, yes. Of course, the MIDI ports may change asynchronously, but it's probably better to have the initial list when the MIDIAccess is populated.
Teleconference 4/6: We can add additional steps to clarify the timing of port population between Step 6 and Step 7 in the algorithm of https://www.w3.org/TR/webmidi/#requestmidiaccess.
Audio Working Group 2023-10-05 meeting conclusions:
Gecko's implementation populates the
MIDIAccess
' ports asynchronously w.r.trequestMIDIAccess()
call. It can therefore be that the promise returned fromrequestMIDIAccess
is resolved, without ports being available. Later,onstatechanged
is fired correctly, then the ports are added.Reading the code, it seems like Chromium resolves the promise returned by
requestMIDIAccess()
after enumeration, is that right? It's probably something that we'd want clarified. It seems like a useful property.