Make MIDIMessageEvent data MIDIConnectionEvent port nullable

[mjwilson-google]

This is to fix #168 and #233.

It seems like there are two possible approaches to fixing these issues:

• One, the "correct" approach as done in this PR, is to make the constructor arguments non-optional and the fields in the dictionaries required. This is how we handle the similar pattern in Web Audio (for example, https://webaudio.github.io/web-audio-api/#OfflineAudioCompletionEvent).
• Two, the "pragmatic" approach is to make the attributes nullable. This is considered pragmatic because we won't have to change Chromium if we do this.

While pragmatism is generally a good thing, I would like to consider this one more time with Gecko and Chromium stakeholders before merging a change.

If it's not a lot of work to update the implementations, and if we don't expect this to break applications, it seems like making the arguments required might be a better API. But, if we feel strongly that it's better to simply make this nullable to move forward more quickly I will modify this change to that form.

[padenot]

Unfortunately we can't make it required now, we have two implementations that have shipped with it being optional.

This is the implementation in Gecko:
https://searchfox.org/mozilla-central/source/dom/midi/MIDIMessageEvent.cpp#66-75
https://searchfox.org/mozilla-central/source/dom/webidl/MIDIMessageEvent.webidl#24
https://searchfox.org/mozilla-central/source/dom/webidl/MIDIConnectionEvent.webidl#23

[chrisguttandin]

Wouldn't this only affect code that calls the event constructors? I mean something like this would be affected, right?

new MIDIConnectionEvent('just-a-type-but-no-options');
new MIDIMessageEvent('just-a-type-but-no-options');

I would argue that this is very rarely done if you are just using the Web MIDI API. It looks like at least on GitHub all code doing something like this is either an implementation of the spec, a polyfill, a platform test or something similar.

https://github.com/search?q=%22new+MIDIConnectionEvent%28%22&type=code
https://github.com/search?q=%22new+MIDIMessageEvent%28%22&type=code

In that case it's maybe still fine to change it.

[mjwilson-google]

@chrisguttandin Thank you for the code links! Yes, it would affect the cases you noted. Even if it's mostly tests and polyfills now, since the API is being used in this way that is more motivation to take the "pragmatic" approach and codify the existing behavior instead of trying to change things.

@padenot Thank you for the Gecko standpoint. Blink has the same standpoint. I will update this PR to make the data and port nullable instead (probably will get to it early next week).

[mjwilson-google]

This makes the data and port nullable. Note that the dictionary elements are not explicitly marked nullable, as per discussion in #233. Both Gecko and Blink should update their IDL after this change.

[padenot]

https://bugzilla.mozilla.org/show_bug.cgi?id=1857420 is the Gecko side for this.

[mjwilson-google]

Chromium CL here: https://crrev.com/c/4917021