Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Are MIDIInputPort and MIDIOutputPort populated during requestMIDIAccess ? #231

Open
padenot opened this issue Mar 10, 2022 · 7 comments
Open
Labels
class: substantive https://www.w3.org/2023/Process-20230612/#correction-classes status: ready for editing Enough information should be available to implement this change in the spec
Milestone

Comments

@padenot
Copy link
Member

padenot commented Mar 10, 2022

Gecko's implementation populates the MIDIAccess' ports asynchronously w.r.t requestMIDIAccess() call. It can therefore be that the promise returned from requestMIDIAccess 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.

@djipco
Copy link

djipco commented Mar 10, 2022

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.

@djipco
Copy link

djipco commented Mar 10, 2022

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?

@padenot
Copy link
Member Author

padenot commented Mar 10, 2022

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.

@djipco
Copy link

djipco commented Mar 10, 2022

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.

@cwilso
Copy link
Contributor

cwilso commented Mar 10, 2022

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.

@hoch
Copy link
Member

hoch commented Apr 6, 2023

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.

@mjwilson-google mjwilson-google added the class: substantive https://www.w3.org/2023/Process-20230612/#correction-classes label Sep 13, 2023
@mjwilson-google mjwilson-google added this to the CR milestone Sep 14, 2023
@mjwilson-google mjwilson-google added status: needs WG review Needs to be discussed with the Audio Working Group before proceeding status: ready for editing Enough information should be available to implement this change in the spec and removed status: needs WG review Needs to be discussed with the Audio Working Group before proceeding labels Sep 30, 2023
@mjwilson-google
Copy link
Contributor

Audio Working Group 2023-10-05 meeting conclusions:

  • Chrome and Firefox currently have different behavior
  • With the new permission model, the spec should codify Firefox's behavior of resolve the promise with the permission and firing the onStateChange event after device enumeration is complete.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
class: substantive https://www.w3.org/2023/Process-20230612/#correction-classes status: ready for editing Enough information should be available to implement this change in the spec
Projects
None yet
Development

No branches or pull requests

5 participants