This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
Currently, the check to throw DataCloneError is performed in the individual types that use it. This caused an oversight: cloning a Blob which has been neutered should throw DataCloneError, but currently doesn't per spec. I'd suggest moving the neutered check out of the type list, and doing it near the top of http://www.whatwg.org/specs/web-apps/current-work/#internal-structured-cloning-algorithm. Otherwise, the neutered check needs to be added to the Blob and File cases.
This doesn't make sense. Only Transferable objects can be neutered, and, with the exception of ArrayBuffer which can be both transfered and copied, Transferable objects can't be copied. There'd be no other type to apply this to. Separate from this, Blob and File objects can be "neutered through the close method". This has nothing to do with Transferable objects being neutered. If a Blob that has been "neutered through the close method" can't be cloned, I'm happy to add something that says as much. Is that the case?
(I'll defer replying to this one, since it'll probably mirror the discussion in #23416.)
Bug 23416 is resolved now; what remains here? Should disabled Blobs not be cloneable? Or should they just be cloned in the disabled state? Do I need to say anything explicitly?
I just think we should avoid having some dead objects throw when cloned and others not. If cloning a dead ArrayBuffer throws, it seems like cloning a dead Blob should too. Alternatively, not throwing at all makes sense: if you post a dead ArrayBuffer, the other side receives an equally dead object.
You can't make an ArrayBuffer go dead, can you? I mean, short of Transferring it, but that's a special case (the rule that applies in that case is just "you can't Transfer an object twice", not "you can't transfer a dead object").
(In reply to Ian 'Hixie' Hickson from comment #5) > You can't make an ArrayBuffer go dead, can you? I mean, short of > Transferring it, but that's a special case (the rule that applies in that > case is just "you can't Transfer an object twice", not "you can't transfer a > dead object"). You can't clone (even without transfer) an ArrayBuffer that's been transferred. If that's going to be the general rule--"you can't clone an object that's been transferred"--then I think you shouldn't be able to clone a Blob that's been closed, either. We have objects that can become inaccessible due to being transferred (ArrayBuffer) and objects that can become inaccessible due to being explicitly killed (Blob.close). I think it's inevitable that we'll have objects that are both, and it seems sucky to have two different ways a single object might be dead, with different effects. (If ArrayBuffer gets a .close() method like Blob, it would become one of those.) So, either 1: yes, cloning a disabled Blob should throw, or 2: ArrayBuffer should no longer throw if cloned while neutered. I lean towards #2. It's simpler, and throwing could be annoying. If you have a big, complex structure you want to hand off, and part of the structure is dead ArrayBuffers or Blobs, it'd force the developer to remove the dead objects, even if they have no other need to remove them. I think throwing an exception when you try to actually access a dead object is enough, and structured clone (and probably transfer, too) should just give the receiver an equally dead object.
> You can't clone (even without transfer) an ArrayBuffer that's been > transferred. Hm, that's an interesting point.
Ok, I've made dead blobs throw as well.
Checked in as WHATWG revision r8310. Check-in comment: Prevent dead Blobs and Files from being cloned http://html5.org/tools/web-apps-tracker?from=8309&to=8310