This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
Require the "data" ArrayBuffer to be neutered during the append to allow the implementation for avoid copying the data internally and prevent races where script modifies the ArrayBuffer while it's being used internally. Suggestion: add wording similar to that added to Web Audio's decodeAudioBuffer method: https://dvcs.w3.org/hg/audio/rev/ef43ae5230bf
Aside from WebAudio there doesn't appear to be any other precedent for "unneutering" a buffer. I talked to Kenneth Russell, one of the Typed Array spec editors, last week about this request and he did not seem very supportive of adding the "unneutering" concept. I'm happy to add text to the MSE spec explicitly pointing out that modifying the buffer while an appendBuffer() operation is pending will lead to undefined behavior. I don't think we should "neuter" and then "unneuter" during the append though since this would make all ArrayBufferViews unavailable for reading during the append. Here is the link to the brief discussion we had on the MediaTF telecon call two weeks ago. (http://www.w3.org/2013/09/24-html-media-minutes.html#item06) FWIW it doesn't appear like Microsoft is going to modify their implementation and at this point I don't see a large enough benefit to modify the Chromium implementation. Also Chromium doesn't currently have the ability to "unneuter" ArrayBuffers so it is unlikely that there is interop on this point even in the WebAudio case.
My original comment was incorrect: there's no possible race because "data" is copied to the internal input buffer synchronously at step 3 of appendBuffer before appendBuffer reaches the asynchronous step 6, so there's no opportunity for the ArrayBuffer to mutate in parallel. I'm happy for this to be closed as invalid. Sorry for wasting your time!