According to http://www.w3.org/html/wg/drafts/html/master/infrastructure.html#safe-passing-of-structured-data (the ArrayBuffer case), trying to clone a neutered ArrayBuffer should throw an exception. Currently, we can't distinguish a neutered buffer from a zero-length buffer, and there are few places to stash an extra bit. This is a followup bug to bug 861925, but I think the problem is preexisting.

Two shell testcases to consider. // TEST 1 var ab = new ArrayBuffer(8); detachArrayBuffer(ab, "change-data"); serialize(ab, []); // should throw a TypeError This is easily fixt by changing JSStructuredCloneWriter::startWrite's JS_IsArrayBufferObject case-handling. // TEST 2 var ab = new ArrayBuffer(8); detachArrayBuffer(ab, "change-data"); serialize(ab, [ab]); But this case is trickier. The ArrayBuffer is written during parsing of the transferables list -- entirely separate code from the startWrite() method above. So that code would need a similar check in it, approximately. But that raises another issue: this problem really can't be limited to just ArrayBuffer, as the spec describes other things as being neuterable/transferable. So we'd need a separate set of checks, sometimes duplicating those in startWrite(), to handle all such possibilities here. Not sure on the easiest fix for all this. It may be about time to make isNeutered() and something like writeForCloning() into MOP operations. Or we could just have a massive thing that checks for all neutered transferables in the other location, still. Or I dunno.

A cross-cutting concern but somewhat related: if you're redoing this code anyway, there's going to have to be a notion of stuff that cannot be transfered cross-process, bug 1232973, notably the first patch on that bug shows WIP.