Reland: Web MIDI: split build rules for media/midi

media/midi/usb_midi_output_stream.cc

Index: media/midi/usb_midi_output_stream.cc
diff --git a/media/midi/usb_midi_output_stream.cc b/media/midi/usb_midi_output_stream.cc
index 2f3289754f082edcae351fa7e5fab3ac0f95ffbe..8f1af70e926b24802dec1c90a5d1374f5a7daec2 100644
--- a/media/midi/usb_midi_output_stream.cc
+++ b/media/midi/usb_midi_output_stream.cc
@@ -98,7 +98,7 @@ bool UsbMidiOutputStream::PushSysExMessage(const std::vector<uint8>& data,
     message[message_size] = byte;
     ++message_size;
     if (byte == kEndOfSysExByte) {
-      uint8 code_index = message_size + 0x4;
+      uint8 code_index = static_cast<uint8>(message_size) + 0x4;

[DaleCurtis, 2015/04/20 16:23:37]

Same question for all these casts, if any of these come from the renderer or can
be influenced by the render it's worrying.

[Takashi Toyoshima, 2015/04/21 06:50:46]

Incoming |data| is parsed inside this while loop, and each message is picked up
from |data|. Each message is less than 3-bytes here by the USB MIDI spec
restriction.

We had one such bug before that malicious renderer can make the browser crash by
specifying out of range index via IPC on Android. Fortunately, clusterfuzz found
it before shipping. For now, we had range checks in IPC receiver, midi_host.cc.
Also, onflight data size is managed by a flow control between renderers and the
browser.

       DCHECK(code_index == 0x5 || code_index == 0x6 || code_index == 0x7);
       data_to_send->push_back((jack_.cable_number << 4) | code_index);
       data_to_send->insert(data_to_send->end(),