Working on bug 1184057, I discovered that we don't lock around mEvents in AudioEventTimeline [0], or message pass, or anything like that. It's being (at least) mutated on the main thread and audio thread (examples: [1], [2]), and read on the audio thread [3]. Either I'm missing something, or I don't know why this works without blowing up at all. This can be pretty high traffic for certain applications. I'm opening this as a sec bug because I'm pretty sure we can do crazy things. [0]: https://dxr.mozilla.org/mozilla-central/source/dom/media/webaudio/AudioEventTimeline.h?offset=0#615 [1]: written on the main thread: https://dxr.mozilla.org/mozilla-central/source/dom/media/webaudio/AudioEventTimeline.h?offset=0#594 [2]: written on the audio thread: https://dxr.mozilla.org/mozilla-central/source/dom/media/webaudio/AudioEventTimeline.h?offset=0#615 [3]: read on the audio thread: https://dxr.mozilla.org/mozilla-central/source/dom/media/webaudio/AudioEventTimeline.h?offset=500#292

AudioParamTimeline is intended for single thread usage. The entire object is copied and passed to the processing thread in AudioNodeStream::SetTimelineParameter(). https://dxr.mozilla.org/mozilla-central/rev/f2518b8a7b97b5bb477e94bc9131584007aac887/dom/media/webaudio/AudioNodeStream.cpp#214

Glad I missed that. Copying potentially massive nsTArrays full of events is not ideal, though.